claude-cli/codex-cli driver's env allowlist drops HOME and every coding-agent credential

[JSONbored]

Problem

The claude-cli/codex-cli CLI-subprocess coding-agent driver's env allowlist (CODING_AGENT_ENV_ALLOWLIST, packages/loopover-engine/src/miner/cli-subprocess-driver.ts:71-85) never passes through HOME/XDG_CONFIG_HOME/XDG_DATA_HOME/XDG_STATE_HOME, nor any coding-agent credential (CLAUDE_CODE_OAUTH_TOKEN, ANTHROPIC_API_KEY, OPENAI_API_KEY, CODEX_ACCESS_TOKEN). This means the spawned claude/codex subprocess can never authenticate at all — not a permission-scope problem (that was #6840, already fixed), a pure "who am I" problem: the subprocess has no HOME to locate a persisted credential file, and no credential env var either.

This is separate from #6840 despite surfacing through the identical-looking claude_code_error_success symptom — #6840's --permission-mode/--allowedTools fix was real and necessary but not sufficient; a live attempt still fails after that fix, now with an explicit "Not logged in · Please run /login" result once the actual cause is isolated.

Reproduction

Confirmed on a real machine, with a real, valid CLAUDE_CODE_OAUTH_TOKEN, replicating the exact env buildAllowlistedEnv constructs for the subprocess today:

$ env -i PATH="$PATH" TERM="$TERM" LANG="$LANG" claude --print --output-format json \
    --permission-mode acceptEdits --allowedTools Read Bash -- 'say hello in 3 words'
{"type":"result","subtype":"success","is_error":true, ...,
 "result":"Not logged in · Please run /login", "terminal_reason":"api_error", ...}

Adding back exactly HOME and CLAUDE_CODE_OAUTH_TOKEN (nothing else) succeeds:

$ env -i PATH="$PATH" TERM="$TERM" LANG="$LANG" HOME="$HOME" CLAUDE_CODE_OAUTH_TOKEN="$CLAUDE_CODE_OAUTH_TOKEN" \
    claude --print --output-format json --permission-mode acceptEdits --allowedTools Read Bash -- 'say hello in 3 words'
{"type":"result","subtype":"success","is_error":false, "result":"Hey there, friend!", ...}

Also confirmed via a full, real loopover-miner attempt <owner/repo> <issue#> --live run with #6840's fix already installed — still failed with the identical claude_code_error_success/zero-turns symptom, because the env-allowlist gap is a distinct, still-live blocker.

Root cause and existing precedent for the fix

This package already has a correct general-purpose allowlist that includes exactly what's missing —
SUBPROCESS_CLI_ENV_ALLOWLIST (packages/loopover-engine/src/subprocess-env.ts:14-32) includes HOME,
XDG_CONFIG_HOME, XDG_DATA_HOME, and XDG_STATE_HOME alongside the same proxy/locale/PATH vars
CODING_AGENT_ENV_ALLOWLIST already has. cli-subprocess-driver.ts defines its own separate, narrower list
instead of using this one, and neither list carries any credential env var name.

Suggested scope for a fix (not investigated further here — this issue is the bug report, not the fix)

• Add HOME/XDG_CONFIG_HOME/XDG_DATA_HOME/XDG_STATE_HOME to whatever allowlist cli-subprocess-driver.ts ends up using (reusing SUBPROCESS_CLI_ENV_ALLOWLIST directly would also retire a duplicate, already-drifted list).
• Explicitly forward only the credential env var that matches the actually-configured provider (not a blanket allowlist of every possible credential name regardless of which provider is in use — an operator with both ANTHROPIC_API_KEY and OPENAI_API_KEY set but running claude-cli should not have the unrelated OPENAI_API_KEY reach the subprocess). packages/loopover-miner/lib/coding-agent-construction.js already knows the resolved provider name at construction time and is a natural place to inject this as the extra/options.env override buildAllowlistedEnv already supports.
• Add a regression test asserting the real, spawned argv's env actually carries HOME and the resolved credential — the existing driver tests, per claude-cli driver's --permission-mode acceptEdits denies every Read/Bash call, silently blocking all real work #6840's own bug report, are argv-shape assertions and didn't catch this gap either.

Impact

This is the primary reason no claude-cli/codex-cli-driven AMS attempt has ever completed real work in production — more fundamental than #6840's permission-mode gap, which was necessary but not sufficient. Both together are required for a live attempt to succeed.

[linear-code]

JSO-4729