Give a worker its login
A worker runs headless, with nobody to answer a login prompt. Give the agent CLI a worker runs on a login or key it can use without one, and end with a check that the worker reaches it.
Which agent CLI runs a work item's tasks is a choice made per task in your templates: every shipped task runs on Claude Code, and Switch a task to another harness moves tasks to another. Kraft calls that CLI a harness. Registering Kraft with the agent you type into, so you can drive Kraft from it, is a different job: see Use Kraft from your agent.
Before you start
- The harness's CLI is installed and on the
PATHof the shell that starts Kraft. - You know which harness the tasks run on. Every shipped task runs on Claude Code.
- If your harness needs an API key, a way to put a variable in the Kraft server's environment (the shell that starts it, or the service's own settings) and to restart the server.
1. Find what your harness needs
Pick your harness. Only Claude Code needs Kraft registered with it, and its tab says how. The other six need no registration: for each, Unattended runs says how Kraft enforces a task's tool rules, or refuses the task when the CLI cannot.
- Registration. Required. An unsandboxed Claude worker asks Kraft's
permission gate through the
kraftMCP server, and Kraft refuses to launch one when nothing registers it. The plugin,kraft admin init, or a committed.mcp.jsoneach count: see Register Kraft with your agent. - Login. Your normal
claudelogin works.ANTHROPIC_API_KEYandCLAUDE_CODE_OAUTH_TOKENreach the worker withoutenv_passthrough. - Check.
claude -p "say hi".
- Login. Sign in with
codex login; the login under your home directory reaches the worker. With an API key, nameCODEX_API_KEYinenv_passthrough, notOPENAI_API_KEY, whichcodex execdoes not send. - Check.
codex exec "say hi".
- Login.
agent loginkeeps the login in the OS keychain, which a worker reaches unless it is sandboxed. With an API key instead, nameCURSOR_API_KEYinenv_passthrough. A sandboxed worker can only use the key. - Check.
agent -p --trust -- "say hi". Run it in a scratch directory:--trustskips Cursor's workspace-trust prompt for the directory you are in.
- Version. OpenCode 2.0.0 or newer. Kraft refuses to launch an older one,
including npm's 1.x
opencode-ai. - Login. Log in to your provider with
opencode auth. A provider key read from the environment needs its variable inenv_passthrough. - Check.
opencode run -- "say hi".
- Login. On a machine where you ran
amp login, do nothing more: the login lives under your home directory, which a worker keeps. A sandboxed repository never sees it, because its workers get a home of their own. There, and on any other machine, create an access token (sgamp_...) at ampcode.com/settings and nameAMP_API_KEYinenv_passthrough. - Check.
amp -x "say hi". Without credentials, Amp prints a device-login prompt and waits about five minutes for a browser before it exits 1, so a hang on that prompt means the credentials did not reach the worker.
- Login. On the machine that runs Kraft, run
agyonce in a terminal and sign in with your Google account. A headless run never signs in by itself: it needs that cached sign-in. The tokens live in the OS keychain and the CLI's state under~/.gemini/antigravity-cli/, both of which a worker keeps. A sandboxed worker reaches neither, and Kraft has not run Antigravity in a sandbox. - Gemini API key. Instead of the sign-in, set
"modelProvider": "gemini"in~/.gemini/antigravity-cli/settings.jsonand nameGEMINI_API_KEYinenv_passthrough. This path is untested in Kraft. - Model. Name a base model and an effort, such as
model: gemini-3.8-flashwitheffort: low, so the dollar caps can price the session.agy modelslists the models your account has. - Check.
agy -p "say hi".
- Login. A Gemini API key or Gemini Code Assist: name
GEMINI_API_KEYinenv_passthrough. An individual Google account (free, Google AI Pro or Ultra) does not work: use the Antigravity tab. - Check.
gemini --skip-trust -p "say hi". Run it in a scratch directory:--skip-trusttrusts the directory you are in for that session.
2. Pass a key to the worker
Skip this step when your harness's tab needs no variable. A worker's environment is an allowlist: a variable reaches it only when the repo's env_passthrough in repos.yaml names it. To pass a key:
- Name its variable in the repo's
env_passthrough. - Export it in the shell that starts the Kraft server. Running Kraft as a service? The service's environment is fixed when
install-servicewrites it, so anexportin your shell never reaches a worker. Set the variable in the service instead, as Give the service an environment shows. - Restart the server.
repos:
- path: /path/to/repo
env_passthrough: [AMP_API_KEY]
Check it worked
- Run your tab's Check command by hand, as the same user that runs the Kraft server. It prints an answer and exits, and does not ask you to log in. Under a service this proves only that your shell has the key: it does not prove the service has it, so read item 2.
- File a small work item with a task on the harness, as Switch a task to another harness shows, and read its log with
kraft view logs ID. A login failure shows there as the CLI's own message: Kraft adds no text of its own. Amp's is in its tab.
Next steps
- Switch a task to another harness: move a chain's tasks onto the harness you gave a login.
- Agent harnesses: what each harness can and cannot do.
- Add or override a harness: add an agent CLI Kraft does not ship.
Build a worker Kit
Build a Docker Sandbox Kit for Kraft's Claude workers, push it to your registry, and run a repository's sandbox from it, pinned by digest.
Remote access
Approve or reject a gate from a phone, over Tailscale, a tunnel or a reverse proxy you run, using the same password auth as the local board, get back if Kraft does not restart, and rotate the token.