openclaw - 💡(How to fix) Fix [Bug]: /think directive rejects all non-off thinking levels on openai/gpt-5.5 — picker shows them but runtime says "Use one of: off" (follow-up to #82975)

Summary

After the picker UI fix that closed #82975, the /think interactive list on canonical openai/gpt-5.5 correctly shows the full range of thinking levels. However, every non-off selection — minimal, low, medium, high, xhigh — is rejected by the directive runtime with the same Use one of: off error from the original issue. The picker filter was patched, but the underlying catalog-metadata / runtime-validation gap on canonical openai/gpt-5.5 was not.

Environment

• OpenClaw v2026.5.18 stable
• Channel: Telegram
• Active agent: main, runtime pi
• agents.defaults.model.primary: openai/gpt-5.5 (1M contextTokens, agentRuntime pi)
• Auth: auth.order.openai = ["openai-codex:[email protected]"] (OAuth, no api-key fallback)
• /status confirms runtime: OpenAI Codex

Reproduction (Telegram)

[19:02] me: /think
[19:02] bot: Current thinking level: xhigh.
             Choose level for /think.
             Options: default, off, minimal, low, medium, high, xhigh.
[19:02] me: xhigh
[19:02] bot: Thinking level "xhigh" is not supported for openai/gpt-5.5.
             Use one of: off.

Repeated the same /think flow with high, medium, low, minimal — every non-off level returns the same Use one of: off rejection. Only off (and default, which resolves to off for this model) is accepted.

Asymmetry vs. the sessions_spawn path

I previously verified in #84489 that the sessions_spawn runtime path accepts non-off thinking in the same environment:

• sessions_spawn(model: "openai/gpt-5.4", thinking: "high") → ✅ completed successfully
• sessions_spawn(model: "openai-codex/gpt-5.5", thinking: "high") → ✅ completed successfully

So the same canonical openai/* namespace is accepted by the spawn path on a sibling model (openai/gpt-5.4) but rejected by the /think directive path on openai/gpt-5.5. Either:

1. The catalog metadata for openai/gpt-5.5 specifically still claims only off is supported (model-specific gap that #82975 fix never patched), or
2. The /think directive validates against a stricter / staler capability check than sessions_spawn does (surface-specific gap).

Either way, the picker UI fix in #82975 made the visible symptom go away while leaving the runtime constraint fully intact, which now manifests one layer down.

Expected

• The /think directive should accept thinking levels consistent with what the picker advertises, OR
• The picker should not advertise levels the directive will reject (i.e. revert the picker side of #82975 for models where the catalog still says off).

The current state is the worst combination: the picker invites the operator to pick any level, then the directive rejects every non-trivial pick.

Workaround

agents.defaults.thinkingDefault: "xhigh" at config-time is honored — the bot reports Current thinking level: xhigh at the start of the picker, and turns appear to use it. Only the interactive /think switch on this model is blocked. No runtime workaround needed; this is primarily a UX-correctness gap that re-exposes the original #82975 root cause.

Related

• #82975 — original "picker only shows default/off" (closed as completed; this issue is the follow-up for the directive-runtime path)
• #84489 — broader subagent/orchestration umbrella where I verified the asymmetric spawn-path behavior