Summary

On openai-codex/gpt-5.5 (and openai-codex/gpt-5.4), the xhigh thinking level is not advertised by /think and typed directives like /think xhigh get remapped to high with the message:

Thinking level set to high (xhigh not supported for openai-codex/gpt-5.5).

This contradicts both the upstream source code and the published documentation, and is a regression from v2026.4.22 (where xhigh was correctly available for openai-codex/gpt-5.4* — gpt-5.5 did not exist in that version).

Why this is a regression, not "expected behavior"

Source code says xhigh should be supported

extensions/openai/openai-codex-provider.ts at tag v2026.4.23, lines 103-112:

const OPENAI_CODEX_XHIGH_MODEL_IDS = [
  OPENAI_CODEX_GPT_55_MODEL_ID,       // "gpt-5.5"
  OPENAI_CODEX_GPT_55_PRO_MODEL_ID,   // "gpt-5.5-pro"
  OPENAI_CODEX_GPT_54_MODEL_ID,       // "gpt-5.4"
  OPENAI_CODEX_GPT_54_PRO_MODEL_ID,   // "gpt-5.4-pro"
  OPENAI_CODEX_GPT_54_MINI_MODEL_ID,  // "gpt-5.4-mini"
  OPENAI_CODEX_GPT_53_MODEL_ID,       // "gpt-5.3"
  "gpt-5.2-codex",
  "gpt-5.1-codex",
] as const;

And at lines 474-478, the provider's resolveThinkingProfile unconditionally adds xhigh when the modelId matches any entry in this list:

resolveThinkingProfile: ({ modelId }) => ({
  levels: [
    { id: "off" }, { id: "minimal" }, { id: "low" },
    { id: "medium" }, { id: "high" },
    ...(matchesExactOrPrefix(modelId, OPENAI_CODEX_XHIGH_MODEL_IDS)
      ? [{ id: "xhigh" as const }]
      : []),
  ],
}),

Documentation says xhigh should be supported

From docs.openclaw.ai/tools/thinking:

xhigh → "ultrathink+" (GPT-5.2+ and Codex models, plus Anthropic Claude Opus 4.7 effort)

openai-codex/gpt-5.4 and openai-codex/gpt-5.5 are both (a) GPT-5.2+ generation and (b) served via Codex OAuth, so they match both phrasings.

v2026.4.22 advertised xhigh for openai-codex/gpt-5.4*

User was on v2026.4.22 immediately before upgrading, and /think for openai-codex/gpt-5.4 listed xhigh as an option. After upgrading to v2026.4.23, /think for the same model no longer lists xhigh. v2026.4.22's XHIGH list (same file, same path) was:

const OPENAI_CODEX_XHIGH_MODEL_IDS = [
  OPENAI_CODEX_GPT_54_MODEL_ID,
  OPENAI_CODEX_GPT_54_PRO_MODEL_ID,
  OPENAI_CODEX_GPT_54_MINI_MODEL_ID,
  OPENAI_CODEX_GPT_53_MODEL_ID,
  OPENAI_CODEX_GPT_53_SPARK_MODEL_ID,
  "gpt-5.2-codex",
] as const;

So the list expanded in v4.23 (added 5.5 + 5.5-pro on top of existing 5.4 family), but in practice none of the entries produce xhigh in the live profile query.

Reproduction

Environment:

• OpenClaw 2026.4.23 (a979721), Linux VM, Node v24.14.0, npm 11.9.0
• Primary agent model: openai-codex/gpt-5.5 via Codex OAuth profile
• openclaw plugins list shows the openai plugin as loaded
• Chat via primary model works normally (so the provider is fully functional for chat)

Steps:

1. Set agents.defaults.model.primary to openai-codex/gpt-5.5 (also reproduces with openai-codex/gpt-5.4).
2. Restart the gateway.
3. Send /think to the agent (via Telegram, CLI, or any other channel).
4. Observe the Options: line.

Actual

Current thinking level: high. Options: off, minimal, low, medium, high.

(no xhigh listed)

Typing /think xhigh replies:

Thinking level set to high (xhigh not supported for openai-codex/gpt-5.5).

Expected

Current thinking level: high. Options: off, minimal, low, medium, high, xhigh.

(per OPENAI_CODEX_XHIGH_MODEL_IDS containing gpt-5.5 and gpt-5.4*)

Attempted local workaround: did not help

We added reasoning: true to each openai-codex entry in models.providers.openai-codex.models[] in case the catalog merge was masking a capability flag the profile resolver needed:

"models": {
  "providers": {
    "openai-codex": {
      "baseUrl": "https://chatgpt.com/backend-api",
      "models": [
        { "id": "gpt-5.5",      "name": "GPT-5.5",      "contextWindow": 1000000, "maxTokens": 128000, "reasoning": true },
        { "id": "gpt-5.4",      "name": "GPT-5.4",      "contextWindow": 1050000, "maxTokens": 128000, "reasoning": true },
        { "id": "gpt-5.4-mini", "name": "GPT-5.4 Mini", "contextWindow": 272000,  "maxTokens": 64000,  "reasoning": true }
      ]
    }
  }
}

Synced to the VM, restarted the gateway: /think still does not list xhigh. So the regression is independent of catalog capability flags.

Root-cause hypothesis

The source chain for /think options eventually calls, in src/plugins/provider-thinking.ts:

export function resolveProviderThinkingProfile(params) {
  return resolveActiveThinkingProvider(params.provider)?.resolveThinkingProfile?.(params.context);
}

Given that the source-level resolveThinkingProfile on the openai-codex provider plugin cleanly appends xhigh for matching modelIds, the most likely failure mode is that resolveActiveThinkingProvider("openai-codex") returns undefined at runtime — i.e. the openai-codex provider plugin is never entered into the thinking registry (globalThis[Symbol.for("openclaw.pluginRegistryState")].activeRegistry.providers), even though the overall openai plugin status is loaded and the provider is fully functional for auth, catalog, and chat.

This would be consistent with a registration ordering or wiring regression introduced somewhere between v4.22 (where the full openai-codex/* thinking profile including xhigh worked end-to-end) and v4.23 (where it silently degrades to the base levels).

Suggested upstream investigation

1. Verify at gateway startup that both openai and openai-codex provider plugin entries appear in activeRegistry.providers — i.e. add a startup log line (debug-level is fine) naming each registered thinking provider id.
2. If only openai is present but openai-codex is missing, trace the registerProvider(buildOpenAICodexProviderPlugin()) call in extensions/openai/index.ts and ensure it is wired through to the thinking registry the same way registerProvider(buildOpenAIProvider()) is.
3. A QA scenario similar to qa/scenarios/models/thinking-slash-model-remap.md but covering openai-codex/gpt-5.5 and openai-codex/gpt-5.4 (not just openai/gpt-5.5) would catch this class of regression.

Related

• [Bug]: sudo --preserve-env=HOME openclaw doctor --fix leaves root-owned files in ~/.npm/_cacache, breaking every subsequent non-root plugin runtime-deps install (EACCES) #71255 — sibling post-install regression on root-owned Linux global installs (sudo doctor + npm cache ownership). Separate root cause, same 4.22→4.23 upgrade window.
• [Bug]: "Unsafe package dist path" error from post-install runtime-deps staging (self-collision) on user-writable global installs (Homebrew Node on macOS) #71261 — sibling post-install "Unsafe package dist path" self-collision on user-writable macOS Homebrew installs. Separate root cause, same upgrade window.

Environment

• OpenClaw: 2026.4.23 (a979721)
• Node: v24.14.0 (NodeSource setup_24.x, apt-held)
• npm: 11.9.0
• OS: Ubuntu 24.04.3 LTS, aarch64 (Linux VM on macOS host)
• Install path: /usr/lib/node_modules/openclaw (via sudo npm install -g [email protected])
• Run mode: user-level systemd --user unit (openclaw-gateway.service)