Bug type

Behavior bug (incorrect output/state without crash)

Summary

openai/gpt-5.3-codex is unconditionally normalized to openai-codex/gpt-5.3-codex at runtime, forcing OAuth-path behavior and failing preflight with Failed to extract accountId from token, even when valid OPENAI_API_KEY is configured — while gpt-5.1-codex and gpt-5.2-codex route correctly via API key on the same host.

Steps to reproduce

1. Configure API-key auth (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

Expected behavior

Request routes through built-in openai provider using API key for gpt-5.3-codex, same as gpt-5.1-codex and gpt-5.2-codex.

Actual behavior

Runtime routes to openai-codex/gpt-5.3-codex and then either:

• Fails preflight with Failed to extract accountId from token, or
• Falls back to Anthropic depending on auth/fallback state

Completion times are 23–67ms (indicating no real inference occurs). No tool calls are executed.

OpenClaw version

2026.2.26 (bc50708)

Operating system

macOS 26.3

Install method

npm global (Homebrew-managed Node/npm)

Logs, screenshots, and evidence

### Runtime logs


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


### 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 — routes through `openai` provider |
| `openai/gpt-5.2-codex` | API key (`sk-proj-*`) | ✅ `tool=read` | ~3.9s | Working — routes through `openai` provider |
| `openai/gpt-5.3-codex` | API key (`sk-proj-*`) | ❌ | 23–67ms | **Fails** — rerouted to `openai-codex`, hits `extractAccountId()` |
| Custom provider → `gpt-5.3-codex` | API key (`sk-proj-*`) | ✅ `tool=read` | 2.7–7.8s | Working (workaround bypasses built-in routing) |

### Source evidence (2026.2.26 dist)

| File | Finding |
|---|---|
| `dist/model-selection-kfr1D9yt.js:15062` | `OPENAI_CODEX_OAUTH_MODEL_PREFIXES = ["gpt-5.3-codex"]` |
| `dist/model-selection-kfr1D9yt.js:15109-15116` | `shouldUseOpenAICodexProvider()` checks provider + model prefix with no API-key intent override |
| `dist/model-selection-kfr1D9yt.js:15120-15125` | `normalizeModelRef()` reroutes `openai/gpt-5.3-codex` → `openai-codex/gpt-5.3-codex` unconditionally |
| `dist/model-BHwbm5WN.js:97` | `CODEX_GPT53_ELIGIBLE_PROVIDERS = new Set(["openai-codex", "github-copilot"])` — `openai` excluded |
| `dist/model-BHwbm5WN.js:115` | API path forced to `openai-codex-responses` |
| `dist/model-picker-*.js:8` | `OPENAI_CODEX_DEFAULT_MODEL = "openai-codex/gpt-5.3-codex"` |

### 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
grep -n 'OPENAI_CODEX_DEFAULT_MODEL' /opt/homebrew/lib/node_modules/openclaw/dist/model-picker-*.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 for built-in provider usage of this model.
Frequency: Deterministic — always occurs when routing through built-in model selection to 5.3.
Consequence: Requests either fail preflight (Failed to extract accountId from token) or route away from intended provider, causing failed task execution and fallback churn. Teams on higher API tiers with multi-developer usage cannot use OAuth/subscription path as a workaround due to throttling limits.

Additional information

Workarounds tested

Suggested fix

1. Respect explicit provider-prefixed refs — openai/gpt-5.3-codex should not be remapped to openai-codex when the user explicitly specified the provider.
2. Allow API-key path for 5.3 on built-in openai provider when OPENAI_API_KEY is present — add "openai" to CODEX_GPT53_ELIGIBLE_PROVIDERS or have shouldUseOpenAICodexProvider() check for existing API key auth before rerouting.
3. Guard extractAccountId() so opaque API keys (sk-*) do not hard-fail preflight — skip JWT decode when token is not a 3-part JWT.

Context

OpenAI enabled standard API key access for gpt-5.3-codex around late February 2026. The onboarding wizard guidance string in this build explicitly directs API key users to openai/gpt-5.1-codex, suggesting 5.3 API key support was not anticipated at build time.