Codex OAuth credentials present, but ACP auth intermittently selects codex-api-key (CODEX_API_KEY is not set)

[handfuloflight]

Summary

When Codex OAuth credentials are present (~/.codex/auth.json with tokens.* and auth_mode=chatgpt), creating a Codex session via SDK can still fail with:

• Internal error
• data: "CODEX_API_KEY is not set"

This indicates ACP auth is selecting codex-api-key rather than chatgpt in some runs.

Environment

• sandbox-agent: 0.2.0
• codex-acp: 0.9.4 (reported by initialize)
• codex CLI: 0.101.0
• deployment: sandbox-agent server on Sprite VM

Repro

1. Ensure OAuth-style Codex file exists:
   • ~/.codex/auth.json contains auth_mode: chatgpt and tokens.access_token/refresh_token
2. Start sandbox-agent without key env injection:
   • no OPENAI_API_KEY and no CODEX_API_KEY in sandbox-agent process env
3. Run SDK createSession/prompt with agent: "codex".
4. Observe failure:
   • CODEX_API_KEY is not set

Contrasting behavior

• If key env is injected (OPENAI_API_KEY/CODEX_API_KEY), the same path progresses but fails provider-side with expected scope error (api.responses.write)—which confirms the ACP route switched to key-based auth.
• In previous runs we also observed successful codex prompt in OAuth-first mode, so this appears intermittent/non-deterministic.

Why this matters

This breaks deterministic operation for OAuth-first deployments and makes recovery testing flaky.

Expected

If OAuth credentials are detected, Codex auth should consistently prefer/attempt chatgpt before failing on missing key env.

Suggested fixes

• deterministic auth method preference when OAuth credentials are present
• explicit SDK/session option to force method (chatgpt/codex-api-key/openai-api-key)
• clearer server-side diagnostic in error payload when auth-method selection occurs

[linear]

RVT-5973