nextv2.0.0
Agents and harnesses

Give a worker its login

Give the agent CLI a worker runs on, whether Claude Code, Codex, Cursor, OpenCode, Amp, Antigravity or Gemini CLI, a login it can use headless, and check that the worker reaches it.

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 PATH of 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 kraft MCP server, and Kraft refuses to launch one when nothing registers it. The plugin, kraft admin init, or a committed .mcp.json each count: see Register Kraft with your agent.
  • Login. Your normal claude login works. ANTHROPIC_API_KEY and CLAUDE_CODE_OAUTH_TOKEN reach the worker without env_passthrough.
  • Check. claude -p "say hi".

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:

  1. Name its variable in the repo's env_passthrough.
  2. Export it in the shell that starts the Kraft server. Running Kraft as a service? The service's environment is fixed when install-service writes it, so an export in your shell never reaches a worker. Set the variable in the service instead, as Give the service an environment shows.
  3. Restart the server.
config/repos.yaml
repos:
  - path: /path/to/repo
    env_passthrough: [AMP_API_KEY]

Check it worked

  1. 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.
  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

Copyright © 2026