feat(auth): support Claude Code subscription tokens via secret.value prefix detection

[nickwinder]

Why

A full A/B sweep against a real SDK costs roughly $135–$270 in per-token API billing (Opus-class models). Claude Code on a Pro / Max / Team / Enterprise plan can authenticate with a long-lived subscription token instead, giving flat-rate billing tied to the plan.

Summary

SandboxAgentConfig stays a single shape — both auth modes flow through the same microsandbox Secret.env() TLS-substitution code path. The runtime sniffs the resolved secret.value's prefix at sandbox-create time and picks which env var name the placeholder lands under:

Resolved value prefix	Sandbox env var
sk-ant-api…	ANTHROPIC_API_KEY (= secret.envVar)
sk-ant-oat…	CLAUDE_CODE_OAUTH_TOKEN

In both cases the cleartext never enters the VM — microsandbox swaps the $MSB_<env-var-name> placeholder for the real value only on outbound TLS to the allowed host (api.anthropic.com for claude).

Point secret.value at the host env var that holds your credential:

"agents": {
  "executor": { "command": "claude", "secret": { "value": "$ANTHROPIC_API_KEY"       } },
  "judge":    { "command": "claude", "secret": { "value": "$CLAUDE_CODE_OAUTH_TOKEN" } }
}

You can mix-and-match per role if you want.

User flow for OAuth

claude setup-token                         # one-time, interactive, ~1yr token
export CLAUDE_CODE_OAUTH_TOKEN='<token>'   # before running the eval

Then set secret: { value: "\$CLAUDE_CODE_OAUTH_TOKEN" } on the sandbox roles you want to bill against the subscription.

End-to-end verification

Smoke-tested against TC-001 with a real Claude Code subscription token + microsandbox VM:

• Egress shows Authorization: Bearer \$MSB_CLAUDE_CODE_OAUTH_TOKEN (the placeholder, pre-substitution) leaving claude
• /api/eval/sdk-… returned 200 and /api/claude_code/settings returned 404 (auth accepted; would be 401 if the placeholder had leaked to the wire) — confirming microsandbox swapped the placeholder for the real OAuth token at TLS time
• Exit 0, real Web SDK solution produced in 27s

Implementation

• applyAgentAuth(secret, adapter, secrets, env) in src/sandbox/microsandbox.ts is now a single path that always pushes a Secret.env(...) entry; the prefix only picks the env var name.
• buildJudgeAllowlist simplified — both modes derive the agent-host allowlist entry from secret.baseUrl (always populated by validation from adapter defaults for known agents).
• Removed the standalone isOAuthSecret helper from the public module surface (inlined as a local conditional inside applyAgentAuth).
• Removed the earlier resolveOAuthToken() and buildAgentSecret() helpers — both subsumed by applyAgentAuth.

Trade-off

Depends on Anthropic's documented OAuth-vs-API-key prefix scheme (sk-ant-oat… vs sk-ant-api…). If that scheme ever changes the eval would route to the wrong env var slot and Claude would respond with an auth error visible in run logs.

Verification

• 328 unit tests pass; type-check + lint clean
• End-to-end TC-001 smoke verified above with real OAuth token + microsandbox + Anthropic API

[HungKNguyen]

My wishlist here is to better compartmentalize the location of each part of the PR. The current architectural is that

• /agents/ contains information about each agent's config, hardcoded secrets, desired env variable
• /core/config.ts handle parsing the config.json and deciding the correct secret.envVar (based on agent's wishes)
• applyAgentAuth should just follow config.ts instruction and inject the secret with actual value

This PR is mising these areas together, but I get why, since the current flow is agent -> config -> secret, but now you need the secret to decide the config. Let me see if I can create a follow up PR for this

[HungKNguyen]

Can approve, concern can be a follow up