Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to 2026.4.26, every request the openai-codex provider
sends to https://chatgpt.com/backend-api/codex/responses is rejected by
the ChatGPT codex backend with HTTP 400
{"detail":"Unsupported parameter: metadata"}. The error is surfaced to
the user as the misleading string 400 status code (no body) because the
SDK error parser expects an {"error":{"message":...}} shape and falls
through. All openai-codex/* models on the ChatGPT subscription path are
unusable until the provider stops attaching metadata to codex requests.

Steps to reproduce

1. OpenClaw 2026.4.26, ChatGPT Plus OAuth profile for the
   openai-codex provider, baseUrl
   https://chatgpt.com/backend-api (default).

2. Run any agent call against a codex model, e.g.

   openclaw agent --local --session-id repro-$$ \
     --message "say hi only" \
     --model openai-codex/gpt-5.4-mini --thinking low
   

3. Observe the agent fail immediately with 400 status code (no body).

Expected behavior

The request succeeds. Sending the same payload manually (without the
metadata field) against the same endpoint with the same OAuth token
returns the assistant message normally — confirmed via curl. Earlier
OpenClaw releases (pre-resolveOpenAITransportTurnState) did not attach
this body field for codex and worked.

Actual behavior

The request body contains a top-level metadata object the codex backend
does not accept; backend responds with HTTP 400 and a 44-byte JSON body
{"detail":"Unsupported parameter: metadata"}. OpenClaw logs only show
error=400 status code (no body) rawError=400 status code (no body)
because the body is shaped {"detail":...}, not the
{"error":{"message":...}} form the SDK error parser expects.

OpenClaw version

2026.4.26 (be8c246)

Operating system

macOS (Darwin 25.4.0)

Install method

npm global

Model

openai-codex/gpt-5.4-mini (also reproduces on gpt-5.4, gpt-5.5)

Provider / routing chain

openclaw → openai-codex (ChatGPT subscription path,
https://chatgpt.com/backend-api/codex/responses) via ChatGPT Plus OAuth

Additional provider/model setup details

Default routing. models.providers.openai-codex.api is
openai-codex-responses and auth is oauth. The transport that fires
is createOpenAIResponsesTransportStreamFn in provider-stream-*.js (uses
the OpenAI SDK with client.responses.create, not the pi-ai
streamOpenAICodexResponses SSE path).

Logs, screenshots, and evidence

Captured via a temporary appendFile in fetch-guard-*.js around the
defaultFetch call, on the failing run:

=== REQ POST https://chatgpt.com/backend-api/codex/responses ===
BODY (parsed top-level keys):
  ['model', 'input', 'stream', 'prompt_cache_key', 'instructions',
   'metadata', 'tools', 'reasoning', 'include', 'store', 'text',
   'parallel_tool_calls']
  metadata: {
    "openclaw_session_id": "...",
    "openclaw_turn_id": "...",
    "openclaw_turn_attempt": "1",
    "openclaw_transport": "stream"
  }

RESP status=400
  content-length: 44
  content-type: application/json
  x-oai-request-id: a9cbd076-0b53-4b88-ba9c-ffa98cc2b98e
  body: {"detail":"Unsupported parameter: metadata"}

Sibling gateway-log evidence (~/.openclaw/logs/gateway.err.log) for
multiple runIDs:

[agent/embedded] embedded run agent end: runId=... isError=true
  model=gpt-5.4-mini provider=openai-codex
  error=400 status code (no body) rawError=400 status code (no body)

Each line is preceded by
[compaction-safeguard] Compaction safeguard: no real conversation messages to summarize… — secondary symptom from the failover loop, not
the root cause.

Impact and severity

• Affected: every OpenClaw user on 2026.4.26 routing through
  openai-codex with a ChatGPT subscription auth profile (the most common
  setup for codex models).
• Severity: High — codex models are completely unusable on this path.
  Fallback chains that include openai-codex/* also break, dragging
  down primary-model recovery.
• Frequency: 100% reproducible on every codex request. Verified across
  gpt-5.4-mini, gpt-5.4, gpt-5.5 and across multiple OAuth profiles.
• Consequence: agents fall through to other providers or surface the
  misleading "400 (no body)" error. The misleading message has caused
  follow-on debugging of OAuth, originator headers, proxy, and session
  state — none of which are the actual cause.

Additional information

Root cause. resolveOpenAITransportTurnState in
extensions/openai/transport-policy.ts returns a metadata block for
all OpenAI-family routes that pass usesKnownNativeOpenAIRoute, which
includes openai-codex against chatgpt.com/backend-api:

return {
  headers: { ...sessionHeaders, "x-openclaw-turn-id": turnId, ... },
  metadata: {
    openclaw_session_id: sessionHeaders["x-openclaw-session-id"] ?? "",
    openclaw_turn_id: turnId,
    openclaw_turn_attempt: attempt,
    openclaw_transport: ctx.transport
  }
};

The codex /backend-api/codex/responses endpoint validates a stricter
parameter allowlist than api.openai.com/v1/responses and does not
accept metadata. buildOpenAIResponsesParams then injects that
metadata into the request body for both endpoints
(...metadata ? { metadata } : {}), and mergeTransportMetadata merges
it again after onPayload. There is no payload-policy gate for
metadata (only store, service_tier, prompt_cache_*), so users
have no config-side workaround; #10140 had previously asked for exactly
such a configurable strip layer.

Suggested fix (smallest surface). In
resolveOpenAITransportTurnState, omit metadata when the provider is
openai-codex. Tracking via x-openclaw-* headers is preserved; the
codex backend ignores arbitrary x- headers. Drop-in patch verified
locally:

const isCodexProvider =
  normalizeProviderId(ctx.provider) === OPENAI_CODEX_PROVIDER_ID;
return {
  headers: {
    ...sessionHeaders,
    "x-openclaw-turn-id": turnId,
    "x-openclaw-turn-attempt": attempt,
  },
  ...isCodexProvider ? {} : {
    metadata: {
      openclaw_session_id: sessionHeaders["x-openclaw-session-id"] ?? "",
      openclaw_turn_id: turnId,
      openclaw_turn_attempt: attempt,
      openclaw_transport: ctx.transport,
    },
  },
};

Verified: same openclaw agent --local --message "say hi only" --model openai-codex/gpt-5.4-mini returns the assistant reply after
applying this patch in dist/transport-policy-*.js. Also confirmed the
manual curl with the unpatched body and metadata: {…} reproduces the
exact 400 with Unsupported parameter: metadata, while removing the
field returns a normal SSE stream.

Possible secondary improvement. The pi-ai error parser falling
through {"detail":...} bodies into "400 status code (no body)" hides
the actual upstream message and meaningfully delayed root-cause analysis.
A small fallback in parseErrorResponse that surfaces a top-level
detail string when no error.message is present would have made this
issue self-diagnosing.

Last known good / first known bad. Last known good: 2026.4.24
(transport-policy turn-state was added between 4.24 and 4.26 along with
the OpenAI-SDK transport switch for codex). First known bad: 2026.4.26.

Related issues

• api=openai-responses (Codex/Responses): gateway online but no replies; repeated 400 (no body) — request normalization / compat options #10140 — old enhancement asking for a configurable
  drop-unsupported-fields layer; would have prevented this if landed.
• createGoogleThinkingPayloadWrapper: strip store/service_tier/metadata only for google-generative-ai (collides with Codex subscription path) #61376 — same family of bug for google-generative-ai OpenAI-compat
  endpoint (rejected metadata / store / service_tier); fix was
  scoped to google-generative-ai only and did not extend to codex.
• [Bug]: /new on openai-codex/* (Responses API) returns "One of input/previous_response_id/prompt/conversation_id must be provided" — regression in 2026.4.26 #73344, openai-codex provider sends empty input[] when context has only systemPrompt → ChatGPT 400 #73820 — separate 4.26 codex regressions on empty input[],
  not the same root cause but compounding the diagnostic difficulty.