openclaw - 💡(How to fix) Fix [Bug]: subagent thinking still rejects non-off on v2026.5.19; previous #84706 was closed against unrelated doctor migration

Summary

v2026.5.19 still rejects non-off thinking for subagent spawns on canonical OpenAI/Codex GPT-5 models. This is not fixed by #84626: that PR is a doctor --fix migration for invalid persisted compat.thinkingFormat config values, not a release-level proof that sessions_spawn(...thinking) accepts non-off thinking.

Previous related issue #84706 was closed by ClawSweeper as "already implemented" because it linked #84626. That close rationale appears incorrect / at least misleading, and after the issue was closed the bot stopped processing follow-up comments. Filing this as a fresh issue so the actual subagent runtime regression is tracked again.

Environment

• OpenClaw v2026.5.19
• /status shows commit a185ca2
• Main session model: openai-codex/gpt-5.5
• Main session thinking: xhigh works through the main-session config/session path
• Subagent runtime: sessions_spawn

Live repro on v2026.5.19

Minimal probe 1:

sessions_spawn({
  runtime: "subagent",
  mode: "run",
  model: "openai/gpt-5.4",
  thinking: "high",
  task: "Reply exactly OK"
})

Result: rejected. The child run reports that openai/gpt-5.4 only supports off.

Minimal probe 2:

sessions_spawn({
  runtime: "subagent",
  mode: "run",
  model: "openai-codex/gpt-5.5",
  thinking: "high",
  task: "Reply exactly OK"
})

Result: rejected with the same shape as before. The effective validation path folds through canonical openai/gpt-5.5 and only accepts off.

Earlier repros also showed thinking: "xhigh" on openai-codex/gpt-5.5 rejecting as:

Thinking level xhigh is not supported for openai/gpt-5.5.
Use one of: off.

Operational impact

This breaks normal subagent orchestration. In our workspace, startup normally spawns a docs-health patrol subagent with:

model: "openai/gpt-5.4",
thinking: "high"

On v2026.5.19 that patrol cannot run as intended. Current workaround is either:

• force subagents to thinking: off, losing the capability; or
• bypass subagents and run the task in the main session.

Why #84626 does not close this

#84626 is titled:

fix(doctor): migrate invalid thinking formats

Its release note in v2026.5.20-beta.1 says:

Doctor: remove unrecognized models.providers.*.models[*].compat.thinkingFormat values during doctor --fix so stale provider model config can validate after upgrade. Fixes #77803.

That scope is a legacy config migration. It removes invalid persisted user config values. It does not by itself prove that the subagent spawn validation path accepts non-off thinking for canonical OpenAI/Codex GPT-5 models.

If commit 6e9d47bd12b0 incidentally contains the real OpenAI/Codex thinking-policy/catalog/subagent fix on main, please point to the exact fix PR/commit and target release for that runtime behavior. But #84626 as described in the release notes should not be treated as the proof for this issue.

Expected behavior / acceptance tests

A release-level fix should prove these exact cases:

1. sessions_spawn(model: "openai/gpt-5.4", thinking: "high") passes validation and completes.
2. sessions_spawn(model: "openai-codex/gpt-5.5", thinking: "high") passes validation and completes.
3. sessions_spawn(model: "openai-codex/gpt-5.5", thinking: "xhigh") either passes if supported by the effective Codex route, or rejects with a correct effective-route capability message — not canonicalize to openai/gpt-5.5 and report Use one of: off.
4. /think picker/runtime and sessions_spawn(...thinking) read from the same reasoning-capability source, so one surface cannot regress while the other appears fixed.

Related

• #84706 — previous report, closed as already implemented by #84626; this appears to be the wrong close rationale.
• #84646 — /think directive / picker surface for the same catalog/capability family.
• #84626 — doctor/config migration for invalid compat.thinkingFormat; not sufficient proof for this runtime subagent issue.