ARD-0046: Share the host's Claude Code login instead of provisioning a token

Status: Accepted Date: 2026-08-05 Deciders: Tom Steigerwald

Decision

boring open forwards the engineer's existing Claude Code credentials into the container after bring-up, and pre-completes the first-run gates that would otherwise sit in front of them. claude setup-token and the CLAUDE_CODE_OAUTH_TOKEN profile secret are no longer required; where both are present, the shared login wins.

Only the claudeAiOauth object is forwarded, plus two ~/.claude.json keys (hasCompletedOnboarding, and hasTrustDialogAccepted for /workspace).

Rationale

The setup-token flow failed the onboarding bar in three separate ways, each of which presents to the user as "boring is broken":

1. It's an extra step before the first boring open, and it lapses silently — the only symptom is an agent pane asking you to log in, weeks later.
2. It doesn't actually authenticate an interactive session. Claude Code reads ~/.claude/.credentials.json; CLAUDE_CODE_OAUTH_TOKEN alone leaves the pane at the login picker. Verified empirically with the env var confirmed present in the container.
3. When it does take effect, it bills as Claude API. With both the env token and a credentials file present, Claude Code prefers the env token and reports Claude API rather than Claude Max — the exact regression ARD-0020 calls non-negotiable.

Valid credentials alone were still not enough: a fresh container is a first run, so Claude Code asks for a text theme, then a login method, then folder trust — three gates in front of a token it hasn't consulted yet. Carrying the onboarding state across is what turns "credentials are present" into "the pane is ready".

Pre-accepting folder trust is defensible here specifically because the profile is the trust anchor (ARD-0006) and the user named this repo on the command line. The sandbox, guardrails, and egress allowlist are what bound the agent; a folder-trust question adds a step without adding safety.

Consequences

Positive. Zero-touch: if the engineer has used Claude Code on their machine, the pane comes up signed in on the correct billing path. Host credentials carry a refresh token, so the container self-renews instead of expiring mid-session. One fewer secret to provision per machine, and one fewer thing to forget to rotate.

Negative. A live subscription credential now enters the sandbox, where a prompt-injected agent could exfiltrate it within the egress allowlist (api.anthropic.com is necessarily open). This is the same shape of exposure ARD-0044 accepted for GH_TOKEN, and bounded the same way: opt out per-repo with claude.auth: false, globally with BORING_NO_CLAUDE_AUTH=1.

Neutral. Delivery is docker exec on stdin, so the value never lands on host disk and never appears in argv (ARD-0002, #41). mcpOAuth.* — tokens for every MCP server the user has authorised — shares the same Keychain record and is deliberately not forwarded; handing an agent the user's whole third-party surface is not a cost worth paying for convenience.

Alternatives Considered

• Keep setup-token, just plumb it correctly. Fixes delivery but not lapse-in-silence, not the extra onboarding step, and not the API-billing regression. Rejected.
• Bind-mount the host ~/.claude directory. Simplest to implement, and drags the user's personal MCP config, project history, and cross-project memory into a project sandbox — the leakage ARD-0029 §3 exists to prevent. Rejected.
• Forward the whole Keychain record. One less jq filter, in exchange for every MCP server token the user holds. Rejected.

Refs: ARD-0020, ARD-0029, ARD-0044, ARD-0006.