Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: openai-codex OAuth requests fail with store:true/stream:false mismatch against /backend-api/codex/responses — error classifier mislabels as "DNS lookup failed" [2 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#67740•Fetched 2026-04-17 08:29:31
View on GitHub
Comments
2
Participants
3
Timeline
7
Reactions
0
Author
zacoharazacohara
Participants
neo1027144-creatorneo1027144-creatorredskul667redskul667zacoharazacohara
Timeline (top)
commented ×2cross-referenced ×2labeled ×2closed ×1

OpenClaw 2026.4.14 sends malformed requests to the Codex OAuth endpoint (https://chatgpt.com/backend-api/codex/responses) that are rejected by OpenAI with HTTP 400 validation errors. After retry/backoff, Cloudflare's edge eventually returns an HTML rate-limit page. OpenClaw's error classifier can't parse the HTML response and mislabels these failures as "DNS lookup for the provider endpoint failed," which sends users down hours of DNS/network debugging that is unrelated to the actual cause.

The /backend-api/codex/responses endpoint requires store: false and stream: true for ChatGPT subscription OAuth tokens, but OpenClaw's Codex plugin appears to force store: true (per the behavior documented at /providers/openai#openai-responses-server-side-compaction, which forces store: true unless model compat sets supportsStore: false).

The documented escape hatch supportsStore: false is rejected by the config schema validator in 2026.4.14: Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore"

Setting responsesServerCompaction: false in the model params also did not resolve the issue.

Error Message

Direct curl progression — proves endpoint works, proves OpenClaw request shape is wrong

All 5 requests made from the same DigitalOcean droplet that runs OpenClaw, using the same OAuth access token pulled from ~/.openclaw/agents/main/agent/auth-profiles.json.

Attempt 1 — minimal payload resembling what OpenClaw appears to send

curl -X POST https://chatgpt.com/backend-api/codex/responses
-H "Authorization: Bearer $TOKEN"
-H "Content-Type: application/json"
-H "OpenAI-Beta: responses=v1"
-d '{"model":"gpt-5.4","input":"hi","stream":false}'

Response: HTTP 400 {"detail":"Instructions are required"}

Attempt 2 — add instructions

-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":"hi","stream":false}'

Response: HTTP 400 {"detail":"Input must be a list"}

Attempt 3 — input as message array

-d '{"model":"gpt-5.4","instructions":"...","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]}],"stream":false}'

Response: HTTP 400 {"detail":"Store must be set to false"}

Attempt 4 — add store:false

-d '{...,"store":false,"stream":false}'

Response: HTTP 400 {"detail":"Stream must be set to true"}

Attempt 5 — correct shape

-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"Say hello in 3 words"}]}],"store":false,"stream":true}'

Response: HTTP 200 with valid SSE stream: event: response.created data: {"type":"response.created","response":{"id":"resp_0e20867d60c4826c0169e108cda8b48191ad41ebf2b91af5f0","status":"in_progress","model":"gpt-5.4","store":false,"service_tier":"auto",...}} event: response.in_progress event: response.output_item.added event: response.content_part.added event: response.output_text.delta ... Full Codex response delivered cleanly.

OpenClaw gateway log excerpt — same runId, cycling through error classifications

15:49:59 warn agent/embedded ... runId=d45f8211-... isError=true error="<html>\n <head>\n <meta name="viewport"..." provider=openai-codex model=gpt-5.4 providerRuntimeFailureKind=unknown 15:50:08 warn agent/embedded ... runId=d45f8211-... (same run) error="⚠️ API rate limit reached. Please try again later." failoverReason=rate_limit providerRuntimeFailureKind=rate_limit 15:50:19 warn agent/embedded ... runId=d45f8211-... (same run) error="LLM request failed: DNS lookup for the provider endpoint failed." providerRuntimeFailureKind=unknown 15:50:34 warn agent/embedded ... runId=d45f8211-... (same run) error="⚠️ API rate limit reached. Please try again later." status=429 failoverReason=rate_limit auth_profile_failure_state_updated: cooldownUntil=..., errorCount=1 15:50:34 warn model-fallback/decision decision=candidate_failed reason=rate_limit status=429 nextCandidateProvider=anthropic nextCandidateModel=claude-sonnet-4-6 15:50:42 warn model-fallback/decision decision=candidate_succeeded candidateProvider=anthropic

All four error classifications share the same rawErrorPreview — the Cloudflare HTML error page. OpenClaw's error classifier cannot parse it and produces four different labels for the same underlying failure.

Config schema rejects documented escape hatch

$ openclaw config set 'models.providers.openai-codex' '{"baseUrl":"https://chatgpt.com/backend-api","api":"openai-responses","models":[{"id":"gpt-5.4","name":"GPT-5.4 (Codex)","supportsStore":false}]}' Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore"

Docs at /providers/openai#openai-responses-server-side-compaction describe supportsStore: false as the model-level compat flag that disables store: true injection. The schema in 2026.4.14 does not accept this key.

Root Cause

OpenClaw 2026.4.14 sends malformed requests to the Codex OAuth endpoint (https://chatgpt.com/backend-api/codex/responses) that are rejected by OpenAI with HTTP 400 validation errors. After retry/backoff, Cloudflare's edge eventually returns an HTML rate-limit page. OpenClaw's error classifier can't parse the HTML response and mislabels these failures as "DNS lookup for the provider endpoint failed," which sends users down hours of DNS/network debugging that is unrelated to the actual cause.

The /backend-api/codex/responses endpoint requires store: false and stream: true for ChatGPT subscription OAuth tokens, but OpenClaw's Codex plugin appears to force store: true (per the behavior documented at /providers/openai#openai-responses-server-side-compaction, which forces store: true unless model compat sets supportsStore: false).

The documented escape hatch supportsStore: false is rejected by the config schema validator in 2026.4.14: Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore"

Setting responsesServerCompaction: false in the model params also did not resolve the issue.

Fix Action

Fix / Workaround

Workarounds Attempted (all unsuccessful)

Current Workaround

Current workaround: Swap primary to an alternate provider (e.g., anthropic/claude-sonnet-4-6), keep openai-codex/gpt-5.4 as fallback. Agent operates but Codex subscription remains unused. Verified working as of 2026-04-16 16:10 UTC.

PR fix notes

PR #67757: fix(openai-codex): resolve OAuth store/stream mismatch and HTML→DNS error misclassification [AI-assisted]

Description (problem / solution / changelog)

Summary

Fixes #67740.

Two interacting bugs cause Codex OAuth requests to fail with a misleading 'DNS lookup failed' error.

Root cause 1: Codex store field not emitted

esolveProviderRequestCapabilities in provider-attribution.ts gates supportsResponsesStoreField on the OPENAI_RESPONSES_APIS set, which did not include openai-codex-responses. This meant the payload policy resolved explicitStore to undefined instead of alse, so the HTTP and WebSocket request builders never set store: false on Codex payloads. The Codex backend (/backend-api/codex/responses) requires store: false — without it, requests are rejected.

Root cause 2: HTML error pages misclassified as DNS

When the Codex backend returns a Cloudflare HTML error page without a parseable HTTP status code in the message body, isHtmlErrorResponse returned alse (it required status >= 400). The error then fell through to isDnsTransportErrorMessage, whose regex matched keywords like 'dns' or 'failed' commonly found in Cloudflare HTML, producing the misleading 'DNS lookup failed' user message.

Changes

src/agents/provider-attribution.ts

Add openai-codex-responses to OPENAI_RESPONSES_APIS so supportsResponsesStoreField returns rue for Codex. This flows through the existing payload policy to emit store: false on both HTTP and WebSocket paths — no changes needed in the transport builders.

src/agents/pi-embedded-helpers/errors.ts

Relax isHtmlErrorResponse to detect HTML error pages even without a parseable status code: when the response has DOCTYPE/html structure plus common CDN/proxy indicators (cloudflare, nginx, error, denied, etc.), classify it as an HTML error page instead of letting it fall through to the DNS matcher.

Verification


  • px vitest run src/agents/provider-attribution.test.ts src/agents/openai-responses-payload-policy.test.ts\ — 30 tests pass

  • px vitest run src/agents/pi-embedded-helpers/provider-error-patterns.test.ts\ — 38 tests pass

Changed files

  • src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts (modified, +12/-0)
  • src/agents/pi-embedded-helpers/errors.ts (modified, +23/-3)
  • src/agents/provider-attribution.test.ts (modified, +22/-0)
  • src/agents/provider-attribution.ts (modified, +1/-1)

PR #67918: fix(openai-codex): unify responses API store capability detection

Description (problem / solution / changelog)

Fixes #67740.

Supersedes #67757 and #67762.

This fixes the still-live Codex Responses store-capability regression on main.

Root cause: we had two different definitions of what counts as a Responses API. provider-attribution.ts excluded openai-codex-responses, while openai-responses-payload-policy.ts included it. That left native Codex OAuth requests without supportsResponsesStoreField, so disable mode omitted the required store: false.

This PR unifies that check behind one shared helper and adds the missing regressions:

  • native openai-codex-responses resolves supportsResponsesStoreField: true
  • disable mode emits explicitStore: false

Verified with:

  • pnpm test src/agents/provider-attribution.test.ts src/agents/openai-responses-payload-policy.test.ts src/agents/pi-embedded-helpers/provider-error-patterns.test.ts src/agents/pi-embedded-helpers.formatassistanterrortext.test.ts

Not changed:

  • no new HTML/DNS error-path logic; the user-facing HTML path is already fixed on main
  • pnpm tsgo is still red on pre-existing unrelated extensions/qa-lab/src/providers/aimock/server.ts failures

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/openai-responses-payload-policy.test.ts (modified, +17/-0)
  • src/agents/openai-responses-payload-policy.ts (modified, +2/-7)
  • src/agents/provider-attribution.test.ts (modified, +22/-0)
  • src/agents/provider-attribution.ts (modified, +11/-2)

Code Example

curl -X POST https://chatgpt.com/backend-api/codex/responses \
  -H "Authorization: Bearer $CODEX_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -H "OpenAI-Beta: responses=v1" \
  -d '{"model":"gpt-5.4","input":"hi","stream":false}'

---

-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":"hi","stream":false}'

---

-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]}],"stream":false}'

---

-d '{"model":"gpt-5.4","instructions":"...","input":[...],"store":false,"stream":false}'

---

-d '{"model":"gpt-5.4","instructions":"...","input":[...],"store":false,"stream":true}'

---

{
    "agents": {
      "defaults": {
        "model": {
          "primary": "openai-codex/gpt-5.4",
          "fallbacks": ["anthropic/claude-sonnet-4-6"]
        },
        "models": {
          "openai-codex/gpt-5.4": {
            "params": {
              "responsesServerCompaction": false,
              "transport": "websocket"
            }
          }
        },
        "embeddedHarness": { "runtime": "pi", "fallback": "pi" }
      }
    }
  }

---

## Direct curl progression — proves endpoint works, proves OpenClaw request shape is wrong

All 5 requests made from the same DigitalOcean droplet that runs OpenClaw, using the same OAuth access token pulled from `~/.openclaw/agents/main/agent/auth-profiles.json`.

### Attempt 1 — minimal payload resembling what OpenClaw appears to send


curl -X POST https://chatgpt.com/backend-api/codex/responses \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "OpenAI-Beta: responses=v1" \
  -d '{"model":"gpt-5.4","input":"hi","stream":false}'

Response: `HTTP 400 {"detail":"Instructions are required"}`

### Attempt 2 — add instructions


-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":"hi","stream":false}'

Response: `HTTP 400 {"detail":"Input must be a list"}`

### Attempt 3 — input as message array


-d '{"model":"gpt-5.4","instructions":"...","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]}],"stream":false}'

Response: `HTTP 400 {"detail":"Store must be set to false"}`

### Attempt 4 — add store:false


-d '{...,"store":false,"stream":false}'

Response: `HTTP 400 {"detail":"Stream must be set to true"}`

### Attempt 5 — correct shape


-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"Say hello in 3 words"}]}],"store":false,"stream":true}'

Response: **HTTP 200** with valid SSE stream:
event: response.created
data: {"type":"response.created","response":{"id":"resp_0e20867d60c4826c0169e108cda8b48191ad41ebf2b91af5f0","status":"in_progress","model":"gpt-5.4","store":false,"service_tier":"auto",...}}
event: response.in_progress
event: response.output_item.added
event: response.content_part.added
event: response.output_text.delta
...
Full Codex response delivered cleanly.

## OpenClaw gateway log excerpt — same runId, cycling through error classifications

15:49:59 warn agent/embedded ... runId=d45f8211-... isError=true
error="<html>\n  <head>\n    <meta name="viewport"..."
provider=openai-codex model=gpt-5.4
providerRuntimeFailureKind=unknown
15:50:08 warn agent/embedded ... runId=d45f8211-... (same run)
error="⚠️ API rate limit reached. Please try again later."
failoverReason=rate_limit
providerRuntimeFailureKind=rate_limit
15:50:19 warn agent/embedded ... runId=d45f8211-... (same run)
error="LLM request failed: DNS lookup for the provider endpoint failed."
providerRuntimeFailureKind=unknown
15:50:34 warn agent/embedded ... runId=d45f8211-... (same run)
error="⚠️ API rate limit reached. Please try again later."
status=429
failoverReason=rate_limit
auth_profile_failure_state_updated: cooldownUntil=..., errorCount=1
15:50:34 warn model-fallback/decision
decision=candidate_failed reason=rate_limit status=429
nextCandidateProvider=anthropic nextCandidateModel=claude-sonnet-4-6
15:50:42 warn model-fallback/decision
decision=candidate_succeeded candidateProvider=anthropic

All four error classifications share the same `rawErrorPreview` — the Cloudflare HTML error page. OpenClaw's error classifier cannot parse it and produces four different labels for the same underlying failure.

## Config schema rejects documented escape hatch

$ openclaw config set 'models.providers.openai-codex' '{"baseUrl":"https://chatgpt.com/backend-api","api":"openai-responses","models":[{"id":"gpt-5.4","name":"GPT-5.4 (Codex)","supportsStore":false}]}'
Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore"

Docs at `/providers/openai#openai-responses-server-side-compaction` describe `supportsStore: false` as the model-level compat flag that disables `store: true` injection. The schema in 2026.4.14 does not accept this key.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Summary

OpenClaw 2026.4.14 sends malformed requests to the Codex OAuth endpoint (https://chatgpt.com/backend-api/codex/responses) that are rejected by OpenAI with HTTP 400 validation errors. After retry/backoff, Cloudflare's edge eventually returns an HTML rate-limit page. OpenClaw's error classifier can't parse the HTML response and mislabels these failures as "DNS lookup for the provider endpoint failed," which sends users down hours of DNS/network debugging that is unrelated to the actual cause.

The /backend-api/codex/responses endpoint requires store: false and stream: true for ChatGPT subscription OAuth tokens, but OpenClaw's Codex plugin appears to force store: true (per the behavior documented at /providers/openai#openai-responses-server-side-compaction, which forces store: true unless model compat sets supportsStore: false).

The documented escape hatch supportsStore: false is rejected by the config schema validator in 2026.4.14: Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore"

Setting responsesServerCompaction: false in the model params also did not resolve the issue.

Environment

  • OpenClaw: 2026.4.14 (323493f)
  • OS: Ubuntu 24.04, Linux 6.8.0-71-generic x64
  • Node: 22.22.0
  • Host: DigitalOcean droplet (2 vCPU / 4GB / Atlanta ATL1)
  • Channels: Slack (socket mode)
  • Auth: ChatGPT Pro $100 subscription via Codex OAuth (plan_type: prolite)
  • Two OAuth profiles present, both with valid tokens (9d expiry)

Reproduction — Direct curl to Codex endpoint

Progressive validation errors show exactly what the endpoint requires. Each response is valid JSON returned directly by OpenAI.

Attempt 1 — OpenClaw-like payload

curl -X POST https://chatgpt.com/backend-api/codex/responses \
  -H "Authorization: Bearer $CODEX_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -H "OpenAI-Beta: responses=v1" \
  -d '{"model":"gpt-5.4","input":"hi","stream":false}'

Response: HTTP 400 {"detail":"Instructions are required"}

Attempt 2 — Add instructions

-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":"hi","stream":false}'

Response: HTTP 400 {"detail":"Input must be a list"}

Attempt 3 — Convert input to message array

-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]}],"stream":false}'

Response: HTTP 400 {"detail":"Store must be set to false"}

Attempt 4 — Add store:false

-d '{"model":"gpt-5.4","instructions":"...","input":[...],"store":false,"stream":false}'

Response: HTTP 400 {"detail":"Stream must be set to true"}

Attempt 5 — Final correct shape

-d '{"model":"gpt-5.4","instructions":"...","input":[...],"store":false,"stream":true}'

Response: HTTP 200, valid SSE stream with event: response.created, event: response.output_text.delta, etc. End-to-end Codex subscription response delivered cleanly from the same host OpenClaw runs on.

Constraint Summary for openai-codex/* OAuth Route

FieldRequired ValueNotes
instructionsnon-empty stringSystem prompt
inputarray of message objectsNot a plain string
storefalseSubscription OAuth cannot persist server-side
streamtrueSubscription OAuth is SSE-only

What OpenClaw Logs Show Instead

Every failed turn cycles through these error classifications for the same runId (the rawErrorPreview in all cases is the same Cloudflare HTML page):

error="<html>...</html>" (providerRuntimeFailureKind: unknown) error="⚠️ API rate limit reached. Please try again later." (rate_limit) error="LLM request failed: DNS lookup for the provider endpoint failed." (unknown) status=429 → failoverReason=rate_limit → fallback_model

The "DNS lookup" message is misleading. DNS resolves fine (dig chatgpt.com returns Cloudflare IPs 104.18.32.47, 172.64.155.209 as expected) and TLS/HTTP/2 connect cleanly.

Workarounds Attempted (all unsuccessful)

  1. Setting models.providers.openai-codex.models[].supportsStore: false → schema rejects as unrecognized key
  2. Setting agents.defaults.models."openai-codex/gpt-5.4".params.responsesServerCompaction: false → config accepted, gateway reloaded, behavior unchanged
  3. Setting params.transport: "websocket" → no change
  4. Setting params.fastMode: false (removing service_tier) → no change
  5. Removing both Codex OAuth profiles and re-authing → no change
  6. openclaw update → already at 2026.4.14, no newer version

Suggested Fix

For any request routed to openai-codex/* provider (OAuth subscription path, not API-key), the Codex plugin should:

  1. Force store: false unconditionally
  2. Force stream: true unconditionally
  3. Ensure instructions field is populated (from agent system prompt)
  4. Ensure input is sent as a message array, not a string

Alternatively: make supportsStore: false a valid model-level config key in the schema (as documented at /providers/openai#openai-responses-server-side-compaction) so users can work around this without waiting for a code fix.

Current Workaround

Switched primary to anthropic/claude-sonnet-4-6 with openai-codex/gpt-5.4 as fallback. Agent operates normally but Codex subscription remains unused despite valid tokens and 99% of 5h/weekly quota available.

Additional Notes

  • Docs at /providers/openai indicate store: true forcing is by design for native OpenAI Responses routes, but the Codex OAuth endpoint behaves differently from the OpenAI API-key endpoint and rejects this
  • The confusion in error messaging ("DNS lookup failed" for what is actually an HTML rate-limit page from Cloudflare) caused several hours of misdirected debugging before isolating the actual failure layer via direct curl tests
  • Full debug trace available on request

Steps to reproduce

  1. Install OpenClaw 2026.4.14 and authenticate with openclaw models auth login --provider openai-codex using a ChatGPT Pro subscription (any tier that includes Codex — confirmed on prolite / $100 Pro).
  2. Set primary model: openclaw models set openai-codex/gpt-5.4
  3. Restart gateway: openclaw gateway restart
  4. Send any prompt through a connected channel (Slack in my case) or trigger any agent turn.
  5. Observe the gateway logs at /tmp/openclaw/openclaw-YYYY-MM-DD.log during the turn.

The turn fails with a cascade of error classifications for the same runId, eventually triggering the configured fallback model. No successful Codex OAuth request is ever made.

To isolate the failure to OpenClaw's request shape (not network/auth/quota), the same host can hit /backend-api/codex/responses directly with curl — progressive 400 validation errors reveal exactly what the endpoint requires. Full curl chain in "Logs, screenshots, and evidence" below.

Expected behavior

The openai-codex/gpt-5.4 provider should successfully route agent requests through the ChatGPT Codex OAuth endpoint (https://chatgpt.com/backend-api/codex/responses), returning model output as SSE chunks.

This expectation is grounded in:

  1. OpenClaw documentation at /providers/openai#option-b-openai-code-codex-subscription states openai-codex/gpt-5.4 is the intended Codex OAuth route and that "OpenAI explicitly supports subscription OAuth usage in external tools/workflows like OpenClaw."

  2. Direct curl to the same endpoint from the same host succeeds with HTTP 200 and a valid SSE stream when the correct request shape is sent (see Logs section, Attempt 5). This confirms the endpoint works and the OAuth token is valid — the failure is in OpenClaw's request construction, not in the environment.

  3. OAuth tokens report healthy state: openclaw models status shows 5h 99% left, Week 99% left, both profiles ok expires in 9d. The usage counter does not move on failed requests, confirming OpenAI never accepts the malformed request against quota.

Actual behavior

Every Codex OAuth request fails. The same runId cycles through multiple error classifications before triggering fallback:

  1. error="<html>...</html>" — Cloudflare HTML error page returned, classified as providerRuntimeFailureKind: unknown
  2. error="⚠️ API rate limit reached. Please try again later." — reclassified as rate_limit
  3. error="LLM request failed: DNS lookup for the provider endpoint failed." — reclassified as unknown
  4. status=429 → failoverReason=rate_limit → decision=fallback_model

The "DNS lookup failed" classification is a misdiagnosis. Direct DNS resolution works (dig chatgpt.com returns Cloudflare IPs 104.18.32.47, 172.64.155.209 as expected), TLS/HTTP/2 negotiation succeeds to the same host, and direct curl requests to the endpoint return valid JSON responses.

Isolation via direct curl to /backend-api/codex/responses from the same OpenClaw host shows OpenAI returns progressive validation errors indicating specific missing/wrong fields in the request body. When the correct fields are supplied, the endpoint returns HTTP 200 with a full SSE response stream. Full curl chain in Logs section.

Observed constraints the endpoint enforces for subscription OAuth that OpenClaw's request does not satisfy:

  • instructions field must be present and non-empty
  • input must be an array of message objects (not a plain string)
  • store must be false (OpenClaw appears to force true per /providers/openai#openai-responses-server-side-compaction)
  • stream must be true

The documented escape hatch supportsStore: false at the model level is rejected by the config schema validator in 2026.4.14: Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore".

Setting agents.defaults.models."openai-codex/gpt-5.4".params.responsesServerCompaction: false is accepted by the validator and hot-reloads, but does not change the failure behavior.

OpenClaw version

2026.4.14 (323493f)

Operating system

Ubuntu (Linux 6.8.0-71-generic x64), DigitalOcean droplet, 2 vCPU / 4GB / 120GB SSD, Intel, ATL1 region

Install method

npm (global install at /usr/lib/node_modules/openclaw, launched via systemd user service openclaw-gateway.service)

Model

openai-codex/gpt-5.4

Provider / routing chain

Agent → openai-codex provider → https://chatgpt.com/backend-api/codex/responses (direct, no proxy) Fallback: anthropic/claude-sonnet-4-6 (API key) No Tailscale, no custom egress proxy, no DNS override. DNS via system default.

Additional provider/model setup details

  • Two Codex OAuth profiles present, both valid:

    • openai-codex:default (managedBy: codex-cli)
    • openai-codex:<account-email> (created by openclaw onboard)
    • Both share the same chatgpt_account_id (same account, same plan, same rate limits)
    • Both reporting healthy: ok expires in 9d
    • chatgpt_plan_type: prolite (ChatGPT Pro $100 tier)

  • Relevant config at time of failure:

  {
    "agents": {
      "defaults": {
        "model": {
          "primary": "openai-codex/gpt-5.4",
          "fallbacks": ["anthropic/claude-sonnet-4-6"]
        },
        "models": {
          "openai-codex/gpt-5.4": {
            "params": {
              "responsesServerCompaction": false,
              "transport": "websocket"
            }
          }
        },
        "embeddedHarness": { "runtime": "pi", "fallback": "pi" }
      }
    }
  }

  • Also tested without responsesServerCompaction: false, without transport override, and with/without fastMode. No combination avoids the failure.

  • openclaw update reports: Before 2026.4.14 → After 2026.4.14 (no newer version available).

Logs, screenshots, and evidence

## Direct curl progression — proves endpoint works, proves OpenClaw request shape is wrong

All 5 requests made from the same DigitalOcean droplet that runs OpenClaw, using the same OAuth access token pulled from `~/.openclaw/agents/main/agent/auth-profiles.json`.

### Attempt 1 — minimal payload resembling what OpenClaw appears to send


curl -X POST https://chatgpt.com/backend-api/codex/responses \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "OpenAI-Beta: responses=v1" \
  -d '{"model":"gpt-5.4","input":"hi","stream":false}'

Response: `HTTP 400 {"detail":"Instructions are required"}`

### Attempt 2 — add instructions


-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":"hi","stream":false}'

Response: `HTTP 400 {"detail":"Input must be a list"}`

### Attempt 3 — input as message array


-d '{"model":"gpt-5.4","instructions":"...","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]}],"stream":false}'

Response: `HTTP 400 {"detail":"Store must be set to false"}`

### Attempt 4 — add store:false


-d '{...,"store":false,"stream":false}'

Response: `HTTP 400 {"detail":"Stream must be set to true"}`

### Attempt 5 — correct shape


-d '{"model":"gpt-5.4","instructions":"You are a helpful assistant.","input":[{"type":"message","role":"user","content":[{"type":"input_text","text":"Say hello in 3 words"}]}],"store":false,"stream":true}'

Response: **HTTP 200** with valid SSE stream:
event: response.created
data: {"type":"response.created","response":{"id":"resp_0e20867d60c4826c0169e108cda8b48191ad41ebf2b91af5f0","status":"in_progress","model":"gpt-5.4","store":false,"service_tier":"auto",...}}
event: response.in_progress
event: response.output_item.added
event: response.content_part.added
event: response.output_text.delta
...
Full Codex response delivered cleanly.

## OpenClaw gateway log excerpt — same runId, cycling through error classifications

15:49:59 warn agent/embedded ... runId=d45f8211-... isError=true
error="<html>\n  <head>\n    <meta name="viewport"..."
provider=openai-codex model=gpt-5.4
providerRuntimeFailureKind=unknown
15:50:08 warn agent/embedded ... runId=d45f8211-... (same run)
error="⚠️ API rate limit reached. Please try again later."
failoverReason=rate_limit
providerRuntimeFailureKind=rate_limit
15:50:19 warn agent/embedded ... runId=d45f8211-... (same run)
error="LLM request failed: DNS lookup for the provider endpoint failed."
providerRuntimeFailureKind=unknown
15:50:34 warn agent/embedded ... runId=d45f8211-... (same run)
error="⚠️ API rate limit reached. Please try again later."
status=429
failoverReason=rate_limit
auth_profile_failure_state_updated: cooldownUntil=..., errorCount=1
15:50:34 warn model-fallback/decision
decision=candidate_failed reason=rate_limit status=429
nextCandidateProvider=anthropic nextCandidateModel=claude-sonnet-4-6
15:50:42 warn model-fallback/decision
decision=candidate_succeeded candidateProvider=anthropic

All four error classifications share the same `rawErrorPreview` — the Cloudflare HTML error page. OpenClaw's error classifier cannot parse it and produces four different labels for the same underlying failure.

## Config schema rejects documented escape hatch

$ openclaw config set 'models.providers.openai-codex' '{"baseUrl":"https://chatgpt.com/backend-api","api":"openai-responses","models":[{"id":"gpt-5.4","name":"GPT-5.4 (Codex)","supportsStore":false}]}'
Error: Config validation failed: models.providers.openai-codex.models.0: Unrecognized key: "supportsStore"

Docs at `/providers/openai#openai-responses-server-side-compaction` describe `supportsStore: false` as the model-level compat flag that disables `store: true` injection. The schema in 2026.4.14 does not accept this key.

Impact and severity

Affected users/systems/channels: All users attempting to use OpenClaw with a ChatGPT Pro/Plus subscription via Codex OAuth (openai-codex/* provider). Every channel connected to an agent using this provider is affected — in my case: 8 Slack channels (#maison-luke, #maison-paul, #maison-bj, #maison-devin, #maison-leadership, #maison-stephen, #maison-production, #ai-sync) plus DMs.

Severity: Blocks workflow entirely for users who configured Codex OAuth as primary. No turns succeed on Codex; all fall through to configured fallback or fail outright if no fallback is configured.

Frequency: 100% — every Codex OAuth request fails. Zero successful Codex turns observed across 30+ attempted turns during debugging.

Consequences:

  • Users paying for ChatGPT Pro ($100 or $200/month) cannot use their subscription through OpenClaw despite this being a documented supported flow.
  • Users with a fallback configured (Anthropic, OpenAI API key, etc.) incur unexpected token costs on the fallback provider while the Codex sub sits unused. 99% of my 5h and weekly Codex quota remains unused.
  • Users without a fallback see complete agent failure.
  • Each failed turn takes ~45 seconds (multiple error classifications + retry cycle) before fallback succeeds, degrading UX in real-time conversations.
  • The misleading "DNS lookup failed" error classification sends users down unrelated debugging paths (DNS config, firewall, proxy, network routing) that cannot resolve the underlying issue. Multiple hours of debugging time lost before isolating via direct curl.

Additional information

Related bug (would recommend filing separately): OpenClaw's error classifier reports HTML response bodies as "LLM request failed: DNS lookup for the provider endpoint failed." This misdiagnosis is the primary reason the request-shape issue takes so long to identify — users reasonably chase DNS/network causes before checking the actual request body. A non-JSON response from the provider endpoint should be classified as something like "provider returned unexpected content-type" rather than reinterpreted as a network-layer failure.

Suggested fix approach for this issue specifically: For the openai-codex/* provider (OAuth subscription path, not API-key), the request builder should unconditionally:

  1. Set store: false
  2. Set stream: true
  3. Populate instructions from the agent's system prompt
  4. Format input as an array of message objects, not a string

Alternatively, accept supportsStore: false as a valid model-level config key in the schema so users can work around this via config until the code fix lands.

Current workaround: Swap primary to an alternate provider (e.g., anthropic/claude-sonnet-4-6), keep openai-codex/gpt-5.4 as fallback. Agent operates but Codex subscription remains unused. Verified working as of 2026-04-16 16:10 UTC.

Not a regression as far as I can observe. This is the first version I've attempted Codex OAuth with, so I have no last-known-good version to cite.

Debug session context: Full debug session available on request. ~3 hours of troubleshooting through the following wrong hypotheses before isolating: DNS/network config, model prefix typos (real but separate bug), embedded harness runtime (real but separate bug), service_tier: priority header rejection, DigitalOcean IP reputation vs Cloudflare. Direct curl to endpoint was the diagnostic step that isolated this in 60 seconds — suggest adding "curl test against provider endpoint directly" to OpenClaw's troubleshooting docs.

extent analysis

TL;DR

The most likely fix is to update the OpenClaw configuration to unconditionally set store: false and stream: true for the openai-codex/* provider.

Guidance

  1. Verify the request shape: Use the provided curl commands to test the endpoint directly and verify that the request shape is correct.
  2. Update the OpenClaw configuration: Set store: false and stream: true unconditionally for the openai-codex/* provider.
  3. Populate instructions and format input: Ensure that the instructions field is populated from the agent's system prompt and that the input field is formatted as an array of message objects.
  4. Test the updated configuration: Restart the OpenClaw gateway and test the updated configuration using the same curl commands.

Example

{
  "models": {
    "providers": {
      "openai-codex": {
        "models": [
          {
            "id": "gpt-5.4",
            "name": "GPT-5.4 (Codex)",
            "store": false,
            "stream": true
          }
        ]
      }
    }
  }
}

Notes

  • The supportsStore: false config key is not currently accepted by the schema, so an alternative solution is to update the code to unconditionally set store: false and stream: true for the openai-codex/* provider.
  • The misleading "DNS lookup failed" error classification should be addressed in a separate issue to prevent similar misdiagnoses in the future.

Recommendation

Apply the workaround by updating the OpenClaw configuration to unconditionally set store: false and stream: true for the openai-codex/* provider, as this is the most straightforward solution to resolve the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The openai-codex/gpt-5.4 provider should successfully route agent requests through the ChatGPT Codex OAuth endpoint (https://chatgpt.com/backend-api/codex/responses), returning model output as SSE chunks.

This expectation is grounded in:

  1. OpenClaw documentation at /providers/openai#option-b-openai-code-codex-subscription states openai-codex/gpt-5.4 is the intended Codex OAuth route and that "OpenAI explicitly supports subscription OAuth usage in external tools/workflows like OpenClaw."

  2. Direct curl to the same endpoint from the same host succeeds with HTTP 200 and a valid SSE stream when the correct request shape is sent (see Logs section, Attempt 5). This confirms the endpoint works and the OAuth token is valid — the failure is in OpenClaw's request construction, not in the environment.

  3. OAuth tokens report healthy state: openclaw models status shows 5h 99% left, Week 99% left, both profiles ok expires in 9d. The usage counter does not move on failed requests, confirming OpenAI never accepts the malformed request against quota.

#api#API rate limit#embedding generation#cache error#pipeline error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING