Set up and run the Labor0 CLI
Use the complete CLI bundle, then return to Manage and troubleshoot for lifecycle recovery. Finish with Run your first task and review Pricing and usage for eligibility and cost terms.
Check prerequisites
Install and sign in to at least one supported coding agent: Codex, Claude Code, or OpenCode. The CLI checks runtime readiness but does not install providers or store their secrets. From the extracted bundle, run l0 doctor (or l0.exe doctor in PowerShell) and resolve the readiness needed for the agent and work you plan to run before authorization. When the bundle directory is not on PATH, use ./l0 doctor on macOS or Linux, or .\labor0-cli\l0.exe doctor in PowerShell.
Sign in to a CLI profile
Run l0 auth login. Complete the HTTPS device-authorization page shown in the terminal, then select a visible Workspace. The terminal flow can accept an invitation or create the first Tenant and Workspace. For the current visible new-account path, open the Labor0 app and sign in. Select New tenant, enter a Name and Slug, and select Create tenant. For example, use Example Studio and example-studio. On Create workspace, confirm Tenant shows Example Studio, enter CLI sandbox for Name and cli-sandbox for Slug, then select Create workspace. Creation is complete when the Workspace selector shows CLI sandbox and its Projects page shows the first-project action; return to l0 auth login and select that Workspace. Add --open-browser only when you want the CLI to open the device-authorization page for you. The CLI creates a key named Labor0 CLI (default), verifies it, and stores only that key in your operating system's credential store. l0 auth status confirms the profile and whether the credential came from secure storage or L0_API_KEY; it never prints the credential.
For a separate account or environment, use a lowercase profile such as l0 --profile work auth login. The --profile flag takes precedence over L0_PROFILE; otherwise default is used. Use L0_API_KEY only for a single automated invocation through an approved secret-injection mechanism. It takes precedence over stored credentials and is never changed by the CLI. Do not put secret values in command arguments.
Run l0 context to confirm the effective workspace and optional project. A one-time --workspace <workspace-id> or --project <project-id> overrides stored profile context. To save a validated choice, run l0 context set --workspace <workspace-id> and add --project <project-id> when needed. The visible completion evidence is validated: true in JSON output or the confirmed workspace and project in human output.
For CI, inject only L0_API_KEY, then select scope explicitly:
No additional identity environment variables are required. Keep secret expansion inside the CI secret mechanism and never enable shell command tracing around the invocation.
Connect a repository and start work
Select the Project with l0 project use <project-id>, then connect the Workspace to the repository owner's GitHub App installation with l0 repository github-app connect. A personal GitHub user link is an additional prerequisite for a user installation and for organization membership proof; when applicable, run l0 repository github-user connect, then complete l0 repository github-app connect. Each connection command prints the authenticated Labor0 page in its progress channel and waits for completion; add --open-browser only when desired. After the GitHub App connection is confirmed, register and bind the repository without placing its URL in argv:
Submit a Graph request through stdin, inspect the pending or proposed revision, and use the exact UUID shown by the command to approve or request changes:
Use the preview UUID and graph-head sequence printed by show in the approval command. After approval, use l0 task list, l0 task start <task-id>, and l0 session watch <session-id>. When watch reports a typed request, use its exact session and request UUIDs. --interactive-input displays the input schema and prompts for one valid JSON value:
For a Plan approval request, use the exact request UUID shown by watch:
Inspect final task state with l0 task show <task-id>, and usage with l0 task usage <task-id> or l0 task billed-usage <task-id>; human monetary values are $-formatted.
See the command reference for exact subcommands and administration workflows.
Authorize one scope
Run l0 runner setup (or ./l0 runner setup from the extracted directory; PowerShell can use .\labor0-cli\l0.exe runner setup). Each local runner owns exactly one immutable Tenant, Workspace, or Project scope. In a terminal, omit the selector to choose the scope kind and enter its UUID interactively. Otherwise select it with exactly one of --tenant <tenant-id>, --workspace <workspace-id>, or --project <project-id>; the flags cannot be combined or inferred from l0 workspace use. For unattended setup, provide an exact selector and --accept-local-execution-consent=v1; use --open-browser when the CLI should open the HTTPS authorization page. Never paste a token or private authorization value into a task, ticket, or chat.
You need Operator or higher permission on the exact scope. Active paid workspaces with an active subscription are eligible regardless of member count; active Sandbox workspaces are eligible with at most one active member. A Workspace or Project runner also requires that Workspace to remain eligible for local execution. A Tenant runner can start when at least one active Workspace is eligible; it can pick up work only from eligible Workspaces, and work in other Workspaces remains queued. The settings page shows the eligible and active Workspace counts before registration.
Consent is stored separately for each exact scope and is required before its runner can start. Read the local-execution consent shown by the command and accept it only when you understand that work runs on the selected computer. Every runner command other than runner list requires its exact scope selector.
Start and check the runner
Start the selected runner and check its status:
Use the same exact selector for a Tenant or Project runner. Multiple configured scopes can run concurrently; status, consent, cache, diagnostics, reconnect, and disconnect remain keyed to the explicitly selected scope. The visible completion evidence is a status result showing the selected scope and the runner as running. l0 runner status --watch --workspace <workspace-id> can follow one scope without printing credentials or task content.
Use a manual runner registration
If a Tenant, Workspace, or Project Settings > Runners page supplies a one-time l0r_ token and daemon command, use that manual setup instead of l0 runner setup. Keep the token in an approved local secret store, download and verify the complete CLI bundle, then run the exact command shown by the app with the extracted runner: ./labor0-runner daemon --server ... --runner-token ... on macOS or Linux, or .\labor0-cli\labor0-runner.exe daemon --server ... --runner-token ... in PowerShell. The token is displayed only once. If the registration is disabled or its token is rotated, repeat the manual setup from the exact-scope settings page; do not use CLI reconnect for it. Parent-scope rows shown in a child settings page are inherited and read-only.
Manual runners have the same Local only boundary as CLI-managed runners: Labor0 cannot confirm selected-runtime readiness for a manual registration, so the browser cannot enable Local only for it. Auto may use hosted fallback, while Local only never falls back to hosted execution.
Optional login service
To run the current-user runner at login, use l0 service install, then confirm with l0 service status. It does not require administrator credentials. Use l0 service start or l0 service restart for recovery. The service must be installed from the same complete bundle that contains the matching l0 and labor0-runner executables.
Complete one bounded first task
In the browser, Auto prefers an eligible active local runner but may use hosted fallback. An active online CLI-managed runner does not currently enable Local only because Labor0 cannot confirm readiness for the selected coding-agent runtime. Local only never falls back to hosted execution. If the final attribution is not Local runner, or hosted fallback is unacceptable, do not submit the browser task with Auto, because hosted work may begin before final attribution is available; stop before retrying.
Open Labor0, select the intended workspace and project, and submit a privacy-safe request such as: “In a scratch branch, add a README heading named Local runner check and show the changed file.” Keep the task small and enable plan review when available. In task or session details, confirm the final Local runner attribution before approving or continuing. The visible completion evidence is the proposed or completed README change and its review state.
What ready looks like
The setup is complete when l0 runner status with the exact selector reports the selected runner as running and Labor0 shows final Local runner attribution.
If setup stops
Return to the command that reported the issue, run l0 doctor, and fix one prerequisite at a time. A missing workspace, consent, or provider readiness result is not fixed by repeating authorization. Use Manage and troubleshoot when the runner was previously connected.