Summary
After upgrading to OpenClaw 2026.4.5, the openai-codex provider consistently fails with Cloudflare 403 responses on the chatgpt.com/backend-api/codex/responses endpoint, despite holding a freshly acquired, valid OAuth token. This makes openai-codex/gpt-5.4 and openai-codex/gpt-5.4-mini effectively unusable as primary models.
This is a continuation / re-file of #62087 (accidentally closed).
Reproduction Steps
- Upgrade to OpenClaw 2026.4.5
- Authenticate:
openclaw models auth login → OpenAI Codex → complete OAuth flow
- Use any agent with
openai-codex/gpt-5.4 or openai-codex/gpt-5.4-mini as primary model
- Observe: every request fails with a Cloudflare 403 HTML response
Direct test (reproduces reliably):
curl -s -o /tmp/test.txt -w '%{http_code}' \
-H 'Authorization: Bearer <valid_access_token>' \
-H 'chatgpt-account-id: <account_id>' \
-H 'originator: pi' \
-H 'User-Agent: pi (linux; x86_64)' \
-H 'OpenAI-Beta: responses=experimental' \
-H 'accept: text/event-stream' \
-H 'content-type: application/json' \
-X POST --data '<valid_payload>' \
https://chatgpt.com/backend-api/codex/responses
# Returns: 403 with Cloudflare HTML bodyNote: The same token against /backend-api/models and /backend-api/usage returns 200 OK — the token is valid. The block is specific to /codex/responses.
Observed Behavior
Gateway logs:
warn {"event":"embedded_run_agent_end","error":"LLM request failed: DNS lookup for the provider endpoint failed.","failoverReason":"auth","model":"gpt-5.4","provider":"openai-codex","rawErrorPreview":"403 <html>\n <head>..."}
warn {"event":"embedded_run_agent_end","error":"API rate limit reached. Please try again later.","failoverReason":"auth","model":"gpt-5.4","provider":"openai-codex","rawErrorPreview":"403 <html>..."}
Misleading error messages: OpenClaw maps the 403 to auth failure reason, then surfaces it as DNS lookup failed or rate limit reached after retry exhaustion — making diagnosis very difficult.
Secondary Issue: OAuth wizard writes invalid config keys
Each re-auth via openclaw models auth login writes token and refreshToken (empty strings) into openclaw.json under the auth profile. The new schema validator in 2026.4.5 rejects these as unrecognized keys, causing gateway startup failures:
Invalid config at /home/openclaw/.openclaw/openclaw.json: Unrecognized keys: "token", "refreshToken"
Workaround: openclaw doctor --fix strips the bad keys. But re-auth rewrites them, so the cycle repeats.
Additionally, each re-auth adds a second profile (openai-codex:<email@gmail.com>) alongside the existing openai-codex:default, causing the retry/fallback loop to attempt both profiles before giving up — doubling the timeout delay on every failed request.
Expected Behavior
openai-codex/gpt-5.4 requests succeed when a valid OAuth token is held- Re-auth does not write
token/refreshToken keys to openclaw.json
- Re-auth does not create duplicate profiles on repeat auth flows
Environment
- OpenClaw version: 2026.4.5
- Provider:
openai-codex
- Models affected:
gpt-5.4, gpt-5.4-mini
- Endpoint:
https://chatgpt.com/backend-api/codex/responses
- OAuth client:
app_EMoamEEZ73f0CkXaXp7hrann
- Token status: Valid (confirmed against
/models and /usage endpoints, expires 2026-04-16)
- Weekly usage: ~43% — not rate limited
- OS: Linux (Ubuntu 20.04, kernel 5.15.0)
Workarounds
- Switch primary model to
anthropic/claude-sonnet-4-6 or another non-Codex provider
- Run
openclaw doctor --fix after each re-auth to remove invalid config keys
- Manually remove duplicate email-based profile from
agents/<name>/agent/auth-profiles.json after each re-auth
References
Summary
After upgrading to OpenClaw 2026.4.5, the
openai-codexprovider consistently fails with Cloudflare 403 responses on thechatgpt.com/backend-api/codex/responsesendpoint, despite holding a freshly acquired, valid OAuth token. This makesopenai-codex/gpt-5.4andopenai-codex/gpt-5.4-minieffectively unusable as primary models.This is a continuation / re-file of #62087 (accidentally closed).
Reproduction Steps
openclaw models auth login→ OpenAI Codex → complete OAuth flowopenai-codex/gpt-5.4oropenai-codex/gpt-5.4-minias primary modelDirect test (reproduces reliably):
Note: The same token against
/backend-api/modelsand/backend-api/usagereturns 200 OK — the token is valid. The block is specific to/codex/responses.Observed Behavior
Gateway logs:
Misleading error messages: OpenClaw maps the 403 to
authfailure reason, then surfaces it asDNS lookup failedorrate limit reachedafter retry exhaustion — making diagnosis very difficult.Secondary Issue: OAuth wizard writes invalid config keys
Each re-auth via
openclaw models auth loginwritestokenandrefreshToken(empty strings) intoopenclaw.jsonunder the auth profile. The new schema validator in 2026.4.5 rejects these as unrecognized keys, causing gateway startup failures:Workaround:
openclaw doctor --fixstrips the bad keys. But re-auth rewrites them, so the cycle repeats.Additionally, each re-auth adds a second profile (
openai-codex:<email@gmail.com>) alongside the existingopenai-codex:default, causing the retry/fallback loop to attempt both profiles before giving up — doubling the timeout delay on every failed request.Expected Behavior
openai-codex/gpt-5.4requests succeed when a valid OAuth token is heldtoken/refreshTokenkeys toopenclaw.jsonEnvironment
openai-codexgpt-5.4,gpt-5.4-minihttps://chatgpt.com/backend-api/codex/responsesapp_EMoamEEZ73f0CkXaXp7hrann/modelsand/usageendpoints, expires 2026-04-16)Workarounds
anthropic/claude-sonnet-4-6or another non-Codex provideropenclaw doctor --fixafter each re-auth to remove invalid config keysagents/<name>/agent/auth-profiles.jsonafter each re-authReferences
@mariozechner/pi-ai→openai-codex-responses.js→buildBaseCodexHeaders()sendsoriginator: piandUser-Agent: pi (linux; x86_64)with no browser cookies or CF clearance token — this headless fingerprint appears to trigger CF mitigation