Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix openai-codex provider auto-defaults api to anthropic-messages instead of openai-codex-responses [2 pull requests, 1 comments, 2 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#64534•Fetched 2026-04-11 06:14:31
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
StaasyStaasy
Participants
neeravmakwananeeravmakwanaStaasyStaasy
Timeline (top)
cross-referenced ×2commented ×1

When openclaw.json defines an openai-codex provider without an explicit api field, the gateway's model registry auto-defaulting logic (introduced in #23332) writes "api": "anthropic-messages" into agents/*/agent/models.json on startup. This causes all openai-codex requests to fail with Cloudflare 403 errors, as the Anthropic message format is sent to chatgpt.com/backend-api.

The correct default for openai-codex should be "openai-codex-responses".

Error Message

The error is classified as auth / model_not_found, triggering failover cascades across all profiles and fallback models.

Root Cause

When openclaw.json defines an openai-codex provider without an explicit api field, the gateway's model registry auto-defaulting logic (introduced in #23332) writes "api": "anthropic-messages" into agents/*/agent/models.json on startup. This causes all openai-codex requests to fail with Cloudflare 403 errors, as the Anthropic message format is sent to chatgpt.com/backend-api.

The correct default for openai-codex should be "openai-codex-responses".

Fix Action

Workaround

Set api explicitly in openclaw.json:

"openai-codex": {
  "baseUrl": "https://chatgpt.com/backend-api",
  "api": "openai-codex-responses",
  "models": []
}

PR fix notes

PR #64561: fix(openai): default openai-codex provider api to responses

Description (problem / solution / changelog)

Summary

  • default openai-codex provider configs without an explicit api to openai-codex-responses
  • add a regression test for the lightweight OpenAI provider policy artifact

Root cause

The lightweight extensions/openai/provider-policy-api.ts public artifact returned providerConfig unchanged for every OpenAI-owned provider. When startup auto-defaulting normalized an openai-codex config that omitted api, it never injected the Codex transport API, so later materialization could persist the wrong transport.

Changes

  • teach the OpenAI provider policy artifact to set api: "openai-codex-responses" when the provider is openai-codex and the field is absent
  • preserve explicit api values unchanged
  • add targeted tests covering both the missing-api and explicit-api cases

Testing

  • pnpm test:extension openai

Closes #64534

Changed files

  • extensions/openai/provider-policy-api.test.ts (added, +45/-0)
  • extensions/openai/provider-policy-api.ts (modified, +8/-0)

PR #64564: Anthropic: scope normalizeConfig hook to Anthropic provider keys

Description (problem / solution / changelog)

Summary

  • Problem: The Anthropic plugin’s global normalizeConfig hook runs for every provider during models.json planning. It called normalizeAnthropicProviderConfig, which adds api: anthropic-messages when a provider has models but no api. That logic was intended only for Anthropic relay setups, but it also matched other providers such as openai-codex, persisting the wrong API type and breaking Codex requests (see #64534).
  • Why it matters: agents/*/agent/models.json could show api: anthropic-messages for openai-codex without an explicit api, sending the wrong wire format to ChatGPT backend URLs.
  • What changed: Introduced normalizeAnthropicProviderConfigForPluginHook in extensions/anthropic/config-defaults.ts so relay API defaulting runs only when the config provider id is anthropic or claude-cli. Wired the Anthropic plugin normalizeConfig hook to use it.
  • What did NOT change: Bundled provider-policy-api for the anthropic artifact and normalizeAnthropicProviderConfig behavior for real Anthropic configs.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #64534
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: normalizeProviderConfigWithPlugin iterates all provider plugins’ normalizeConfig hooks. Anthropic’s hook applied normalizeAnthropicProviderConfig without checking ctx.provider, so any provider with models and no api received anthropic-messages.
  • Missing detection / guardrail: Provider-scoped guard on the hook body.
  • Contributing context (if known): N/A

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/anthropic/config-defaults.normalize-hook.test.ts
  • Scenario the test should lock in: openai-codex with models and no api must not get api: anthropic-messages from the hook; anthropic and claude-cli still get the relay default when appropriate.
  • Why this is the smallest reliable guardrail: Exercises the exported hook helper directly.
  • Existing test that already covers this (if any): None for this cross-provider case.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

models.json generation no longer injects api: anthropic-messages for non-Anthropic providers when api is omitted. Users configuring openai-codex without an explicit api should no longer see that incorrect default from this hook.

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: Linux / macOS (local dev)
  • Runtime/container: N/A
  • Model/provider: openai-codex (config without api)
  • Integration/channel (if any): N/A
  • Relevant config (redacted): models.providers.openai-codex with baseUrl + models only

Steps

  1. Configure openai-codex with models and no api, restart gateway or run models json refresh.
  2. Inspect agents/<agent>/agent/models.json (before fix: erroneous api: anthropic-messages for that provider when the hook ran).

Expected

Non-Anthropic providers do not receive Anthropic relay api defaults from this hook.

Actual

Hook returns undefined for openai-codex; relay default still applies for anthropic / claude-cli.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: Unit tests for the hook helper; pnpm test extensions/anthropic/config-defaults.normalize-hook.test.ts passes.
  • Edge cases checked: anthropic and claude-cli still get relay default when models exist and api is missing.
  • What you did not verify: Full gateway E2E against live ChatGPT backend.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

None.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/anthropic/config-defaults.normalize-hook.test.ts (added, +48/-0)
  • extensions/anthropic/config-defaults.ts (modified, +18/-0)
  • extensions/anthropic/register.runtime.ts (modified, +2/-2)

Code Example

"openai-codex": {
     "baseUrl": "https://chatgpt.com/backend-api",
     "models": [
       { "id": "gpt-5.4", "name": "GPT-5.4", "reasoning": true, "input": ["text"] }
     ]
   }

---

rawError=403 <html>...(Cloudflare block page)...

---

"openai-codex": {
  "baseUrl": "https://chatgpt.com/backend-api",
  "api": "openai-codex-responses",
  "models": []
}
RAW_BUFFERClick to expand / collapse

Description

When openclaw.json defines an openai-codex provider without an explicit api field, the gateway's model registry auto-defaulting logic (introduced in #23332) writes "api": "anthropic-messages" into agents/*/agent/models.json on startup. This causes all openai-codex requests to fail with Cloudflare 403 errors, as the Anthropic message format is sent to chatgpt.com/backend-api.

The correct default for openai-codex should be "openai-codex-responses".

Steps to reproduce

  1. Configure openai-codex provider in openclaw.json without an api field: 
    "openai-codex": {
  "baseUrl": "https://chatgpt.com/backend-api",
  "models": [
    { "id": "gpt-5.4", "name": "GPT-5.4", "reasoning": true, "input": ["text"] }
  ]
}
  2. Restart the gateway (or run openclaw update)
  3. Check agents/main/agent/models.json — the api field is set to "anthropic-messages"
  4. All openai-codex model requests fail with 403

Expected behavior

The gateway should default api to "openai-codex-responses" for the openai-codex provider, matching the built-in provider definition in buildOpenAICodexProvider().

Actual behavior

The auto-defaulting logic sets api: "anthropic-messages", causing the wrong transport to be used. Gateway logs show:

rawError=403 <html>...(Cloudflare block page)...

The error is classified as auth / model_not_found, triggering failover cascades across all profiles and fallback models.

Workaround

Set api explicitly in openclaw.json:

"openai-codex": {
  "baseUrl": "https://chatgpt.com/backend-api",
  "api": "openai-codex-responses",
  "models": []
}

Context

  • This worked on v2026.4.5 where api was left unset in both openclaw.json and models.json, and the runtime resolved it correctly via resolveCodexForwardCompatModel().
  • The regression likely comes from the auto-defaulting fix in #23332 which defaults api by provider name but doesn't handle openai-codex correctly.
  • Related: #38706, #22409

Environment

  • OpenClaw v2026.4.9
  • Node.js v22.22.1
  • Ubuntu Linux

extent analysis

TL;DR

Set the api field explicitly to "openai-codex-responses" in the openai-codex provider configuration in openclaw.json to fix the Cloudflare 403 errors.

Guidance

  • Verify that the api field is being auto-defaulted to "anthropic-messages" by checking the agents/*/agent/models.json file after startup.
  • Update the openclaw.json configuration to include the api field with the correct value, as shown in the provided workaround example.
  • Test the updated configuration to ensure that openai-codex requests are successful and no longer return 403 errors.
  • Be aware that this issue is specific to OpenClaw v2026.4.9 and may not affect other versions.

Example

"openai-codex": {
  "baseUrl": "https://chatgpt.com/backend-api",
  "api": "openai-codex-responses",
  "models": []
}

Notes

The provided workaround should resolve the issue, but it's essential to note that this is a regression introduced in version 2026.4.9, and the correct default value for the api field should be handled by the auto-defaulting logic.

Recommendation

Apply the workaround by setting the api field explicitly to "openai-codex-responses" in the openai-codex provider configuration, as this is a reliable solution to resolve the Cloudflare 403 errors.

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 gateway should default api to "openai-codex-responses" for the openai-codex provider, matching the built-in provider definition in buildOpenAICodexProvider().

#api#ISR setup#authentication setup#request error#file not found

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix openai-codex provider auto-defaults api to anthropic-messages instead of openai-codex-responses [2 pull requests, 1 comments, 2 participants]