✨ feat: Support Codex OAuth login flow instead of requiring API key

[bdougie]

Summary

tapes start codex currently requires a service account API key (sk-svcacct-...) via tapes auth openai. This forces users off Codex's native OAuth login flow (codex login). We should support the OAuth flow so users can authenticate the way Codex intends.

Background

tapes start claude works seamlessly because Claude CLI uses a simple API key pattern — tapes stores the key, injects it as ANTHROPIC_API_KEY, and points ANTHROPIC_BASE_URL at the proxy. OpenAI/Codex doesn't follow this pattern — Codex CLI uses OAuth via codex login (through auth.openai.com), storing tokens in ~/.codex/auth.json.

Today, configureCodexAuth() in cmd/tapes/start/start.go:836-871:

1. Requires an OpenAI API key from ~/.tapes/credentials.toml
2. Patches ~/.codex/auth.json to inject the API key
3. Strips OAuth tokens via PatchCodexAuthKey() in pkg/credentials/codex.go:44 (delete(auth, "tokens"))

This means users must have a service account key and can't use codex login.

What Needs to Change

1. pkg/credentials/codex.go — Stop stripping OAuth tokens

• PatchCodexAuthKey() deletes the "tokens" field (line 44). Add a mode that preserves OAuth tokens, or split into two functions: one for API key patching, one for OAuth-aware mode.

2. cmd/tapes/start/start.go — Make configureCodexAuth() OAuth-aware

• If ~/.codex/auth.json already has valid OAuth tokens (from codex login), skip the API key patching entirely. Just let the proxy forward the OAuth bearer tokens.
• Remove the hard requirement for tapes auth openai when OAuth tokens exist.
• Fallback chain: OAuth tokens → API key → error with instructions.

3. proxy/proxy.go — Verify OAuth path coverage

• isOpenAIAuthPath() (line 736) already routes /oauth/*, /auth/*, /oauth2/* etc. to auth.openai.com via resolveOpenAIAuthUpstream() (line 696).
• Verify this covers all paths that codex login and token refresh use. May need to add token refresh endpoints if not already covered.

4. Proxy header passthrough — Already works

• header.go already passes Authorization headers through transparently. OAuth bearer tokens will flow to api.openai.com without changes.

Key Files

File	What to change
pkg/credentials/codex.go	Preserve OAuth tokens instead of deleting them
cmd/tapes/start/start.go (configureCodexAuth)	Detect existing OAuth tokens, skip API key requirement
proxy/proxy.go (isOpenAIAuthPath)	Audit OAuth/token-refresh path coverage

Acceptance Criteria

• codex login + tapes start codex works without tapes auth openai
• tapes auth openai + tapes start codex (API key path) still works as fallback
• OAuth token refresh flows through the proxy correctly
• Proxy still captures and stores conversation turns from OAuth-authenticated requests

References

• Codex app-server docs: https://developers.openai.com/codex/app-server
• codex login uses auth.openai.com for OAuth

[linear]

PCC-326

[BakedSoups]

#176

[jpmcb]

We should support the OAuth flow so users can authenticate the way Codex intends.

I don't think supporting OAuth flows directly in the proxy is the right approach: tapes should transparently pass through whatever Authorization header that is given to it and the tapes auth command is abit problematic since it subsumes the proxy to carry auth behind it (which defeats the purpose of a transparent proxy).

Codex can already work with the tapes proxy: setting the following in ~/.codex/config.toml

model = "gpt-5.1"
model_provider = "proxy"

[model_providers.proxy]
name = "OpenAI using LLM proxy"
base_url = "http://localhost:8080"

and then running tapes with:

tapes serve --upstream https://chatgpt.com/backend-api/codex/responses --provider openai

works as expected and connects (see this comment from the codex repo: anomalyco/opencode#1686 (comment)). There are other problems since it seems this backend seems to speak a different "dialect" than what we have in the proxy providers.