Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix agent: --thinking minimal rejected by openai-codex provider; default + retry causes per-turn latency [1 pull requests, 1 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#71946•Fetched 2026-04-27 05:37:01
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
1OAKDesign1OAKDesign
Participants
1OAKDesign1OAKDesign
Timeline (top)
referenced ×4closed ×1cross-referenced ×1

openclaw agent defaults thinking to minimal (and --thinking minimal is in --help), but the openai-codex responses API rejects it for gpt-5.5 / gpt-5.4-mini:

Unsupported value: 'minimal' is not supported with the 'gpt-5.5' model.
Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.

The embedded runner catches and retries with low:

[agent/embedded] unsupported thinking level for openai-codex/gpt-5.5; retrying with low

So end users see correct results, but every agent turn pays a wasted first call + retry latency. In a cron-driven autonomous setup this adds up fast.

Root Cause

Root cause hypothesis

Fix Action

Fix / Workaround

Local workaround

PR fix notes

PR #71980: fix(codex): translate --thinking minimal to low for modern Codex models (#71946)

Description (problem / solution / changelog)

Summary

Fixes #71946.

The CLI defaults thinkLevel to minimal. Modern Codex models (gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.2) use the none/low/medium/high/xhigh effort enum and reject minimal:

Unsupported value: 'minimal' is not supported with the 'gpt-5.5' model.
Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.

The pi-embedded-runner has a retry-with-low fallback that catches this — but every agent turn on these models pays a wasted first request + retry latency. In autonomous / cron setups that compounds.

This translates minimal → low upfront in extensions/codex/src/app-server/thread-lifecycle.ts#resolveReasoningEffort for modern models, branching on the existing isModernCodexModel() helper. Older Codex models still receive minimal directly. The runner-side retry stays as belt-and-suspenders.

The reporter explicitly identified provider-side translation as the preferred path (option 1 in the issue).

Pre-implement audit (skill v6 rules)

RuleStatusNotes
Existing-helper checkPASSisModernCodexModel already exists in provider.ts; exported so thread-lifecycle can reuse
Shared-helper-caller checkPASSresolveReasoningEffort has one caller (buildCodexTurnStartParams); contract change is additive (model param)
Broader-fix rival scanPASSNo open rival PR for this issue

Files

file+−
CHANGELOG.md10
extensions/codex/provider.ts51
extensions/codex/src/app-server/thread-lifecycle.ts143
extensions/codex/src/app-server/thread-lifecycle.test.ts540 (new)

Test plan

  • 16 new unit tests in thread-lifecycle.test.ts covering:
    • modern models translate minimal → low
    • modern models pass low/medium/high/xhigh through unchanged
    • case-variant model ids (GPT-5.5, gpt-5.4-mini) normalize correctly
    • legacy models (gpt-5, gpt-4o, o3-mini, codex-mini-latest) preserve minimal
    • empty/unknown models conservatively preserve minimal
    • off / undefined thinkLevel returns null
  • pnpm exec vitest run extensions/codex/src/app-server/thread-lifecycle.test.ts — 16/16 pass
  • pnpm exec oxfmt --check — clean
  • pnpm exec oxlint — 0 warnings/errors
  • CI green
  • Manual repro with openclaw agent --thinking minimal --message hi against gpt-5.5 — should not emit unsupported thinking level warning

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/codex/provider.ts (modified, +5/-1)
  • extensions/codex/src/app-server/thread-lifecycle.test.ts (added, +59/-0)
  • extensions/codex/src/app-server/thread-lifecycle.ts (modified, +15/-3)

Code Example

Unsupported value: 'minimal' is not supported with the 'gpt-5.5' model.
Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.

---

[agent/embedded] unsupported thinking level for openai-codex/gpt-5.5; retrying with low

---

openclaw agent --agent main --message "hi" --thinking minimal --timeout 30
RAW_BUFFERClick to expand / collapse

Summary

openclaw agent defaults thinking to minimal (and --thinking minimal is in --help), but the openai-codex responses API rejects it for gpt-5.5 / gpt-5.4-mini:

Unsupported value: 'minimal' is not supported with the 'gpt-5.5' model.
Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.

The embedded runner catches and retries with low:

[agent/embedded] unsupported thinking level for openai-codex/gpt-5.5; retrying with low

So end users see correct results, but every agent turn pays a wasted first call + retry latency. In a cron-driven autonomous setup this adds up fast.

Repro

openclaw agent --agent main --message "hi" --thinking minimal --timeout 30

Expected: clean execution. Actual: stderr Unsupported value: 'minimal' ... retrying with low. Final result OK; first attempt wasted.

Without --thinking at all, same result (the default appears to be minimal).

Affected combos

  • openai-codex/gpt-5.5
  • openai-codex/gpt-5.4-mini
  • presumably any codex model using the new effort enum (none/low/medium/high/xhigh).

Root cause hypothesis

CLI levels: off | minimal | low | medium | high Codex responses API accepts: none | low | medium | high | xhigh

minimal isn't translated for the codex adapter. Two fixes either side:

  1. Provider-side mapping: in the openai-codex adapter, translate minimal → low at request build time (preserves user-facing CLI semantics).
  2. CLI-default change: default --thinking to low for codex-backed models.

Local workaround

Pass --thinking low explicitly everywhere openclaw agent is invoked. Confirmed eliminates the failed-first-call path.

Version

OpenClaw 2026.4.24 (cbcfdf6)

extent analysis

TL;DR

Update the default thinking level for codex-backed models to low to avoid the initial failed call and retry latency.

Guidance

  • Verify the issue by running the repro command and checking for the "Unsupported value" error followed by a retry with low thinking level.
  • Consider implementing a provider-side mapping in the openai-codex adapter to translate minimal to low at request build time.
  • As a temporary workaround, pass --thinking low explicitly when invoking openclaw agent to eliminate the failed-first-call path.
  • Review the affected model combinations, including openai-codex/gpt-5.5 and openai-codex/gpt-5.4-mini, to ensure the fix applies to all relevant cases.

Example

No code snippet is provided as the issue is related to configuration and API compatibility.

Notes

The fix may require updates to the openai-codex adapter or changes to the default thinking level in the openclaw agent configuration. The workaround of passing --thinking low explicitly can be used until a permanent fix is implemented.

Recommendation

Apply the workaround by passing --thinking low explicitly when invoking openclaw agent, as this is a simple and effective way to avoid the initial failed call and retry latency.

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#model loading#dependency error#configuration error#environment variable

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 agent: --thinking minimal rejected by openai-codex provider; default + retry causes per-turn latency [1 pull requests, 1 participants]