Bug type

Behavior bug (incorrect output/state without crash)

Summary

gpt-5.3-codex cannot complete tool-requiring tasks via API key due to two independent bugs: (1) built-in routing forces the model to the OAuth-only openai-codex provider (#30844, PRs pending), and (2) even when routing is bypassed via custom provider, the Responses API rejects requests with 400 Item 'function_call' was provided without its required 'reasoning' item (related to #18282). gpt-5.2-codex and gpt-5.1-codex work correctly on the same config.

Steps to reproduce

Blocker 1 — Routing (covered by #30844):

1. Configure OPENAI_API_KEY via openclaw onboard --auth-choice openai-api-key
2. Set agents.defaults.model.primary to openai/gpt-5.3-codex
3. Restart gateway
4. Run any agent turn
5. Observe: runtime normalizes to openai-codex/gpt-5.3-codex and fails with Failed to extract accountId from token

Blocker 2 — Reasoning/function_call payload (bypassing Blocker 1 via custom provider):

1. Define a custom provider in models.providers pointing to https://api.openai.com/v1 with api: "openai-responses" and your API key
2. Set agents.defaults.model.primary to <custom-provider>/gpt-5.3-codex
3. Restart gateway
4. Run any tool-requiring agent turn
5. Observe: 400 Item 'function_call' ... was provided without its required 'reasoning' item

Expected behavior

gpt-5.3-codex routes through the openai provider using API key auth and executes tool calls, same as gpt-5.2-codex and gpt-5.1-codex.

Actual behavior

Blocker 1: Runtime normalizes openai/gpt-5.3-codex → openai-codex/gpt-5.3-codex. The openai-codex provider attempts JWT decode on the API key via extractAccountId(), which fails pre-flight:

Failed to extract accountId from token

Blocker 2: When routing is bypassed via custom provider, requests reach OpenAI but are rejected:

400 Item 'function_call' ... was provided without its required 'reasoning' item

Tested with thinking=off, thinking=low, and no thinking param — all produce the same 400 error on 5.3. Does not occur on gpt-5.2-codex or gpt-5.1-codex with identical config.

OpenClaw version

2026.2.26 (bc50708)

Operating system

macOS 26.3

Install method

npm global (Homebrew-managed Node/npm)

Logs, screenshots, and evidence

### Control tests (same host, same API key)

| Provider/Model | Auth | Tool calls | Duration | Status |
|---|---|---|---|---|
| `openai/gpt-5.1-codex` | API key (`sk-proj-*`) | ✅ `tool=read` | ~5.5s | Working |
| `openai/gpt-5.2-codex` | API key (`sk-proj-*`) | ✅ `tool=read` | ~3.9s | Working |
| `openai/gpt-5.3-codex` (built-in) | API key (`sk-proj-*`) | ❌ | 23–67ms | Fails — Blocker 1 (routing) |
| `openai/gpt-5.3-codex` (custom provider) | API key (`sk-proj-*`) | ❌ | ~15.6s | Fails — Blocker 2 (reasoning/function_call) |

### Runtime logs — Blocker 1


embedded run start: ... provider=openai-codex model=gpt-5.3-codex ...
embedded run agent end: ... isError=true error=Failed to extract accountId from token


### Runtime logs — Blocker 2


embedded run start: ... provider=openai-api model=gpt-5.3-codex ...
embedded run agent end: ... isError=true error=400 Item 'function_call' ... was provided without its required 'reasoning' item


### Source evidence — Blocker 1

| File | Finding |
|---|---|
| `dist/model-selection-kfr1D9yt.js:15062` | `OPENAI_CODEX_OAUTH_MODEL_PREFIXES = ["gpt-5.3-codex"]` |
| `dist/model-selection-kfr1D9yt.js:15109-15125` | `shouldUseOpenAICodexProvider()` + `normalizeModelRef()` unconditionally reroute `openai/gpt-5.3-codex` → `openai-codex/gpt-5.3-codex` |
| `dist/model-BHwbm5WN.js:97` | `CODEX_GPT53_ELIGIBLE_PROVIDERS = new Set(["openai-codex", "github-copilot"])` — `openai` excluded |

### Repro verification commands


grep -n 'OPENAI_CODEX_OAUTH_MODEL_PREFIXES' /opt/homebrew/lib/node_modules/openclaw/dist/model-selection-*.js
grep -n 'CODEX_GPT53_ELIGIBLE_PROVIDERS' /opt/homebrew/lib/node_modules/openclaw/dist/model-*.js

Impact and severity

Affected: Teams using OpenAI API-key billing who need gpt-5.3-codex in OpenClaw 2026.2.26.
Severity: Workflow-blocking — no viable built-in path to run 5.3 with tool use on API key.
Frequency: Deterministic — Blocker 1 always occurs via built-in routing; Blocker 2 always occurs on tool-requiring tasks via custom provider.
Consequence: Teams must downgrade to gpt-5.2-codex or gpt-5.1-codex. OAuth/subscription path is not viable at team scale due to throttling limits.

Additional information

Blocker 1 has PRs pending: #30848 and #30849 (filed via #30844).

Blocker 2 appears related to #18282 (reasoning item pairing in Responses API payloads), originally reported for gpt-5.2-chat-latest in multi-turn context. The 5.3 variant differs in that it fails on the first tool-requiring turn, not after session accumulation. Additional 5.3 repro details posted as a comment on #18282.

Resolving Blocker 1 alone (routing fix) is insufficient — users will immediately hit Blocker 2 when attempting tool use on 5.3 via API key. Both fixes are needed to make gpt-5.3-codex usable on the API key path.