Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Regression: Codex ChatGPT accounts hard-fail when session switches to openai-codex/gpt-5.4-mini [4 pull requests, 2 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#74451•Fetched 2026-04-30 06:23:50
View on GitHub
Comments
2
Participants
2
Timeline
12
Reactions
2
Author
0xCyda0xCyda
Participants
0xCyda0xCydaclawsweeper[bot]clawsweeper[bot]
Timeline (top)
cross-referenced ×5referenced ×3commented ×2closed ×1

Regression: this worked in 2026.4.23, but on 2026.4.26 an OpenClaw session running on the Codex ChatGPT backend hard-fails when it switches to openai-codex/gpt-5.4-mini.

Error Message

{"type":"message","timestamp":"2026-04-29T14:47:40.885Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}} {"type":"message","timestamp":"2026-04-29T14:54:25.728Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}} {"type":"message","timestamp":"2026-04-29T14:59:43.482Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}

Root Cause

So this does not look like it was caused by a manual models-config change.

Fix Action

Fixed

PR fix notes

PR #74507: fix(models): reject suppressed inline model rows with api

Description (problem / solution / changelog)

Summary

  • Problem: Configured inline model rows with api bypass the suppression check, allowing openai-codex/gpt-5.4-mini to resolve even though ChatGPT-backed Codex accounts do not support it
  • Why it matters: Users with stale config entries see repeated runtime failures instead of a clear rejection
  • What changed: Added suppression check before returning inline matches in resolveExplicitModelWithRegistry
  • What did NOT change: Suppression logic itself unchanged; only the check placement extended

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 #74451
  • Related #73242, #73280
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: resolveExplicitModelWithRegistry returns inlineMatch when inlineMatch?.api exists BEFORE checking shouldSuppressBuiltInModel, allowing stale configured rows to bypass suppression
  • Missing detection / guardrail: No suppression check for inline matches with explicit api
  • Contributing context: User had gpt-5.4-mini in their openclaw.json from before the suppression was added

Regression Test Plan (if applicable)

  • Coverage level:
    • Unit test
  • Target test file: src/agents/pi-embedded-runner/model.test.ts
  • Scenario the test should lock in: Configured openai-codex/gpt-5.4-mini inline row with api: "openai-codex-responses" is rejected with the suppression message
  • Why this is the smallest reliable guardrail: Tests the exact resolver path that was bypassing suppression
  • Existing test that already covers this: None for inline rows with api

User-visible / Behavior Changes

  • Configured openai-codex/gpt-5.4-mini with api now returns the suppression error instead of failing at runtime

Diagram (if applicable)

Before:
[configured inline row with api] -> [returns inlineMatch] -> [runtime error from vendor]

After:
[configured inline row with api] -> [suppression check] -> [clear rejection with guidance]

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

Repro + Verification

Environment

  • OS: macOS 24.6.0
  • Runtime/container: Node.js v25.6.1
  • Model/provider: openai-codex
  • Integration/channel: N/A

Steps

  1. Add gpt-5.4-mini with api: "openai-codex-responses" to models.providers.openai-codex.models[] in config
  2. Try to use openai-codex/gpt-5.4-mini
  3. Observe rejection with suppression message instead of runtime failure

Expected

  • Clear rejection: "gpt-5.4-mini is not supported by the OpenAI Codex OAuth route..."

Actual

  • Works as expected after fix

Evidence

  • Failing test/log before + passing after
pnpm test src/agents/pi-embedded-runner/model.test.ts
# 69 tests passed (1 new)

New test verifies:

expect(result.error).toBe(
  "Unknown model: openai-codex/gpt-5.4-mini. gpt-5.4-mini is not supported by the OpenAI Codex OAuth route. Use openai/gpt-5.4-mini with an OpenAI API key or openai-codex/gpt-5.5 with Codex OAuth.",
);

Human Verification (required)

  • Verified scenarios: Unit tests pass (69/69), code review, resolver logic inspection
  • Edge cases checked: Configured row with and without api, suppression check ordering
  • What you did NOT verify: E2E with live Codex session (unit tests cover the resolver path)

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

Risks and Mitigations

  • Risk: Could reject valid configured models if suppression is too broad
    • Mitigation: Only applies to models explicitly marked as suppressed in plugin manifest; existing suppression logic unchanged

Changed files

  • docs/cli/skills.md (modified, +13/-7)
  • docs/help/faq.md (modified, +7/-4)
  • docs/tools/clawhub.md (modified, +6/-2)
  • docs/tools/skills.md (modified, +14/-10)
  • src/agents/pi-embedded-runner/model.test.ts (modified, +29/-0)
  • src/agents/pi-embedded-runner/model.ts (modified, +8/-0)
  • src/cli/skills-cli.commands.test.ts (modified, +115/-0)
  • src/cli/skills-cli.ts (modified, +31/-10)

PR #74511: fix(models): reject suppressed inline model rows with api

Description (problem / solution / changelog)

Summary

  • Problem: Configured inline model rows with api bypass the suppression check, allowing openai-codex/gpt-5.4-mini to resolve even though ChatGPT-backed Codex accounts do not support it
  • Why it matters: Users with stale config entries see repeated runtime failures instead of a clear rejection
  • What changed: Added suppression check before returning inline matches in resolveExplicitModelWithRegistry
  • What did NOT change: Suppression logic itself unchanged; only the check placement extended

Regression: Worked in 2026.4.23, broken in 2026.4.26. The suppression was added in dc6031197b but only covered built-in/discovered rows, not configured inline rows with explicit api.

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 #74451
  • Related #73242, #73280
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: resolveExplicitModelWithRegistry returns inlineMatch when inlineMatch?.api exists BEFORE checking shouldSuppressBuiltInModel, allowing stale configured rows to bypass suppression
  • Missing detection / guardrail: No suppression check for inline matches with explicit api
  • Contributing context: User had gpt-5.4-mini in their openclaw.json from before the suppression was added

Regression Test Plan (if applicable)

  • Coverage level:
    • Unit test
  • Target test file: src/agents/pi-embedded-runner/model.test.ts
  • Scenario the test should lock in: Configured openai-codex/gpt-5.4-mini inline row with api: "openai-codex-responses" is rejected with the suppression message
  • Why this is the smallest reliable guardrail: Tests the exact resolver path that was bypassing suppression
  • Existing test that already covers this: None for inline rows with api

User-visible / Behavior Changes

  • Configured openai-codex/gpt-5.4-mini with api now returns the suppression error instead of failing at runtime

Diagram (if applicable)

Before:
[configured inline row with api] -> [returns inlineMatch] -> [runtime error from vendor]

After:
[configured inline row with api] -> [suppression check] -> [clear rejection with guidance]

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

Repro + Verification

Environment

  • OS: macOS 24.6.0
  • Runtime/container: Node.js v25.6.1
  • Model/provider: openai-codex
  • Integration/channel: N/A

Steps

  1. Add gpt-5.4-mini with api: "openai-codex-responses" to models.providers.openai-codex.models[] in config
  2. Try to use openai-codex/gpt-5.4-mini
  3. Observe rejection with suppression message instead of runtime failure

Expected

  • Clear rejection: "gpt-5.4-mini is not supported by the OpenAI Codex OAuth route..."

Actual

  • Works as expected after fix

Evidence

  • Failing test/log before + passing after
pnpm test src/agents/pi-embedded-runner/model.test.ts
# 69 tests passed (1 new)

New test verifies:

expect(result.error).toBe(
  "Unknown model: openai-codex/gpt-5.4-mini. gpt-5.4-mini is not supported by the OpenAI Codex OAuth route. Use openai/gpt-5.4-mini with an OpenAI API key or openai-codex/gpt-5.5 with Codex OAuth.",
);

Human Verification (required)

  • Verified scenarios: Unit tests pass (69/69), code review, resolver logic inspection
  • Edge cases checked: Configured row with and without api, suppression check ordering
  • What you did NOT verify: E2E with live Codex session (unit tests cover the resolver path)

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

Risks and Mitigations

  • Risk: Could reject valid configured models if suppression is too broad
    • Mitigation: Only applies to models explicitly marked as suppressed in plugin manifest; existing suppression logic unchanged

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-embedded-runner/model.test.ts (modified, +29/-0)
  • src/agents/pi-embedded-runner/model.ts (modified, +9/-0)

PR #74655: fix(models): unconditionally suppress stale openai-codex/gpt-5.4-mini inline entries (#74451)

Description (problem / solution / changelog)

Summary

Fixes #74451.

openclaw doctor --fix writes explicit openai-codex/gpt-5.4-mini rows into models.list with an api field. On ChatGPT-backed Codex accounts, the manifest suppresses gpt-5.4-mini via providerConfigApiIn, but resolveExplicitModelWithRegistry was only checking conditional suppressions (which are bypassable by explicit user config). The inline api-carrying row bypassed the suppression and caused repeated 400s at runtime.

Fix

Three-part change:

  1. src/plugins/manifest-model-suppression.ts — expose unconditionalOnly flag on the resolver (suppressions with no when clause fire always, regardless of user config)
  2. src/agents/model-suppression.ts — add shouldUnconditionallySuppress helper that calls the resolver with unconditionalOnly: true
  3. src/agents/pi-embedded-runner/model.ts — in resolveExplicitModelWithRegistry, gate inline matches on unconditional suppressions before returning

Conditional suppressions (e.g. qwen Coding Plan endpoint guard with providerConfigApiIn) are NOT affected — they remain bypassable by explicit user configuration. This preserves the existing resolves explicitly configured qwen3.6-plus before Coding Plan built-in suppression test.

Tests

src/agents/pi-embedded-runner/model.test.ts — 2 new regression tests:

  • Configured openai-codex/gpt-5.4-mini inline entry with api is suppressed
  • Configured qwen3.6-plus (conditional suppression) still resolves
Tests  69 passed (69)

Greptile P2 addressed

PR #74511 (rival) has a clawsweeper P2: "Use an explicit unconditional suppression path or corrected condition semantics." This PR implements exactly that path — shouldUnconditionallySuppress + unconditionalOnly flag — with coverage for both the unconditional and conditional suppression cases.

Audit

  • Audit A (existing helper): shouldSuppressBuiltInModel exists; new shouldUnconditionallySuppress is a distinct function that calls the same resolver with unconditionalOnly: true, not a reimplementation
  • Audit B (shared callers): resolveExplicitModelWithRegistry — 1 caller. New guard is additive (new suppression gate), no contract change for valid non-suppressed inputs
  • Audit C (broader rival): PR #74511 (3 files) addresses the same issue but lacks the unconditionalOnly API that clawsweeper's P2 explicitly requested. This PR (5 files) adds the missing API layer and covers both test cases

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/model-suppression.ts (modified, +16/-0)
  • src/agents/pi-embedded-runner/model.test.ts (modified, +42/-0)
  • src/agents/pi-embedded-runner/model.ts (modified, +9/-0)
  • src/plugins/manifest-model-suppression.ts (modified, +4/-0)

PR #74871: fix(openai): remove incorrect gpt-5.4-mini suppression on openai-codex route

Description (problem / solution / changelog)

Summary

Removes the modelCatalog.suppressions entry that blocks openai-codex/gpt-5.4-mini. The model is available and works on the Codex OAuth route — the suppression is a regression introduced in 4.27.

Fixes #74451 — the original issue was that users got repeated runtime failures when switching to openai-codex/gpt-5.4-mini. #74655 improved suppression enforcement for stale inline entries, which is a valid resolver improvement, but it isn't the fix needed here. The underlying problem is that the suppression itself is incorrect — the model works on the Codex OAuth route and should not be suppressed.

Context

  • openai-codex/gpt-5.4-mini worked on 4.23 and earlier with no issues
  • The 4.27 suppression blocks the model before the request reaches the API
  • Verified the model works via the Codex app-server SDK (codex/gpt-5.4-mini) on a ChatGPT-backed OAuth account
  • #74655's unconditional suppression code only fires when a manifest suppression entry exists — removing the entry makes it a no-op

Test plan

  • Verify openai-codex/gpt-5.4-mini resolves and completes requests on a ChatGPT-backed Codex OAuth account
  • Verify existing gpt-5.3-codex-spark suppressions are unaffected
  • pnpm test src/agents/pi-embedded-runner/model.test.ts

Changed files

  • extensions/openai/openclaw.plugin.json (modified, +0/-5)

Code Example

{"type":"custom","customType":"model-snapshot","data":{"timestamp":1777474052260,"provider":"openai-codex","modelApi":"openai-codex-responses","modelId":"gpt-5.4-mini"},"timestamp":"2026-04-29T14:47:32.260Z"}
{"type":"message","timestamp":"2026-04-29T14:47:40.885Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}
{"type":"message","timestamp":"2026-04-29T14:54:25.728Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}
{"type":"message","timestamp":"2026-04-29T14:59:43.482Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}
RAW_BUFFERClick to expand / collapse

Summary

Regression: this worked in 2026.4.23, but on 2026.4.26 an OpenClaw session running on the Codex ChatGPT backend hard-fails when it switches to openai-codex/gpt-5.4-mini.

Regression

  • Worked fine in: 2026.4.23
  • Broken in: 2026.4.26

Config note

There were no intentional changes to the models config related to this failure.

Current config still has:

  • primary model: openai-codex/gpt-5.4
  • openai-codex/gpt-5.4-mini present in the configured OpenAI Codex model list

openclaw.json was written recently, but only for unrelated reasons:

  • 2026-04-28: openclaw mcp set trendtrack ...
  • 2026-04-29: openclaw doctor --non-interactive --fix

So this does not look like it was caused by a manual models-config change.

What happened

  • Session was running normally on openai-codex/gpt-5.4
  • Runtime switched the session to openai-codex/gpt-5.4-mini
  • Multiple assistant turns then failed with:
    • The 'openai-codex/gpt-5.4-mini' model is not supported when using Codex with a ChatGPT account.
  • Runtime later switched the session back to openai-codex/gpt-5.4

Expected

One of these should happen instead:

  1. OpenClaw should know gpt-5.4-mini is unsupported for ChatGPT-backed Codex accounts and block the switch before it is applied
  2. It should fall back automatically to a supported model like openai-codex/gpt-5.4
  3. At minimum, the model-change path should fail safe without causing repeated assistant-turn failures

Actual

The session accepted the unsupported model selection, then assistant turns failed repeatedly at runtime.

Environment

  • Worked in OpenClaw: 2026.4.23
  • Broken in OpenClaw: 2026.4.26
  • Backend/provider: openai-codex
  • API adapter: openai-codex-responses
  • Account type: ChatGPT-backed Codex account
  • Surface: Discord

Evidence

Exported log slice:

  • /home/brandon/.openclaw/workspace/exports/openclaw-gpt-5.4-mini-chatgpt-account-issue-2026-04-29.md

Relevant transcript entries:

{"type":"custom","customType":"model-snapshot","data":{"timestamp":1777474052260,"provider":"openai-codex","modelApi":"openai-codex-responses","modelId":"gpt-5.4-mini"},"timestamp":"2026-04-29T14:47:32.260Z"}
{"type":"message","timestamp":"2026-04-29T14:47:40.885Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}
{"type":"message","timestamp":"2026-04-29T14:54:25.728Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}
{"type":"message","timestamp":"2026-04-29T14:59:43.482Z","message":{"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"openai-codex/gpt-5.4-mini","stopReason":"error","errorMessage":"The model is not supported when using Codex with a ChatGPT account."}}

Repro idea

  1. Use OpenClaw with a ChatGPT-backed Codex account
  2. Switch the active model for a session to openai-codex/gpt-5.4-mini
  3. Send a normal user message
  4. Observe the assistant turn fail instead of falling back or rejecting the switch earlier

Suggested fix

Add capability gating for account-backed Codex models so unsupported models like openai-codex/gpt-5.4-mini cannot be selected for incompatible account types.

extent analysis

TL;DR

Implement capability gating for account-backed Codex models to prevent selection of unsupported models like openai-codex/gpt-5.4-mini for ChatGPT-backed Codex accounts.

Guidance

  • Verify the account type and model compatibility before switching models to prevent unsupported model selections.
  • Consider adding a fallback mechanism to automatically switch to a supported model like openai-codex/gpt-5.4 when an unsupported model is selected.
  • Review the OpenClaw configuration and model list to ensure that only supported models are listed for ChatGPT-backed Codex accounts.
  • Test the capability gating and fallback mechanisms with different account types and models to ensure correct behavior.

Example

No code example is provided as the issue does not specify the exact implementation details.

Notes

The suggested fix assumes that the issue is caused by the lack of capability gating for account-backed Codex models. However, the root cause may be more complex and require additional investigation.

Recommendation

Apply the suggested fix by implementing capability gating for account-backed Codex models to prevent selection of unsupported models. This will help prevent repeated assistant-turn failures and ensure a better user experience.

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…
#api#index setup#retrieval issue#search optimization#API routing

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 Regression: Codex ChatGPT accounts hard-fail when session switches to openai-codex/gpt-5.4-mini [4 pull requests, 2 comments, 2 participants]