openclaw - 💡(How to fix) Fix [Bug]: 2026.5.27 Codex runtime rejects openai/gpt-5.5; codex/gpt-5.5 workaround drops Telegram /status usage

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading a live VPS from OpenClaw 2026.5.26 to 2026.5.27, the previously working openai/gpt-5.5 + Codex runtime route began failing with Requested agent harness "codex" does not support openai/gpt-5.5; switching the configured route to codex/gpt-5.5 restored model execution but Telegram /status stopped showing Codex 5h/week usage.

Steps to reproduce

1. Run OpenClaw 2026.5.26 with a Telegram-routed main agent using openai/gpt-5.5 through the OpenAI Codex runtime/auth path.
2. Confirm Telegram /status shows the model plus Codex usage windows. Observed before upgrade:

   OpenClaw 2026.5.26 (0e30120)
   Model: openai/gpt-5.5
   Runtime: OpenAI Codex
   Usage: 5h 99% left ... Week 74% left ...

3. Upgrade the same VPS to OpenClaw 2026.5.27 stable.
4. Send a Telegram message in the affected topic while the agent is still configured for openai/gpt-5.5 + Codex runtime.
5. Observe the gateway rejecting the primary candidate and falling back to Gemini.
6. As a live workaround, change the configured route to codex/gpt-5.5 with agentRuntime.id = "codex" and a Gemini fallback.
7. Send Telegram /status again.

Expected behavior

Either:

• openai/gpt-5.5 remains the supported user-facing route for Codex runtime agents, as it did in 2026.5.26 and as described by earlier routing work; or
• if 2026.5.27 intentionally made codex/gpt-5.5 a supported/expected user-facing route, Telegram /status should still map that active provider to Codex subscription usage and show the 5h/week usage windows.

Actual behavior

With openai/gpt-5.5 on 2026.5.27, the gateway repeatedly rejected the primary candidate and used fallback:

2026-05-29T15:55:19+00:00 [diagnostic] lane task error: lane=main durationMs=337 error="Error: Requested agent harness "codex" does not support openai/gpt-5.5 (provider is not one of: codex)."
2026-05-29T15:55:19+00:00 [diagnostic] lane task error: lane=session:agent:main:telegram:group:-1003871627242:topic:6823 durationMs=343 error="Error: Requested agent harness "codex" does not support openai/gpt-5.5 (provider is not one of: codex)."
2026-05-29T15:55:19+00:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=unknown next=google/gemini-2.5-flash detail=Requested agent harness "codex" does not support openai/gpt-5.5 (provider is not one of: codex).
2026-05-29T15:55:23+00:00 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=openai/gpt-5.5 candidate=google/gemini-2.5-flash reason=unknown next=none

The same pattern was observed several times later in the same gateway process:

2026-05-29T16:53:09+00:00 [diagnostic] lane task error: lane=session:agent:main:telegram:group:-1003871627242:topic:6823 durationMs=234 error="Error: Requested agent harness "codex" does not support openai/gpt-5.5 (provider is not one of: codex)."
2026-05-29T16:53:09+00:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=unknown next=google/gemini-2.5-flash detail=Requested agent harness "codex" does not support openai/gpt-5.5 (provider is not one of: codex).
2026-05-29T16:53:15+00:00 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=openai/gpt-5.5 candidate=google/gemini-2.5-flash reason=unknown next=none

After changing the live config to codex/gpt-5.5, execution worked again, but Telegram /status no longer included the usage line. Observed Telegram status after the workaround:

OpenClaw 2026.5.27 (0e30120)
Model: codex/gpt-5.5
Fallbacks: google/gemini-3.1-pro-preview
Context: 0/200k (0%)
Session: agent:main:telegram:group:-1003871627242:topic:6823
Execution: direct · Runtime: OpenAI Codex · Think: off · Fast: off
Voice: inbound ...
Activation: always · Queue: steer (depth 0)

No Usage: line was shown there, although the same VPS can still fetch Codex usage through CLI status:

$ openclaw status --usage
OpenClaw 2026.5.27 (27ae826)
...
Usage:
  Codex (pro ($0.00))
    5h: 97% left · resets 3h 6m
    Week: 67% left · resets 1d 1h

OpenClaw version

OpenClaw 2026.5.27 (27ae826)

Last known good observed version: OpenClaw 2026.5.26 (0e30120)

Operating system

Ubuntu 24.04.3 LTS, aarch64

Kernel from openclaw status: linux 6.17.0-1011-oracle (arm64)

Install method

Global npm/system install:

/usr/bin/openclaw -> /usr/lib/node_modules/openclaw/openclaw.mjs

Gateway runs as a systemd user service.

Model

Before upgrade / expected canonical route:

openai/gpt-5.5
Runtime: OpenAI Codex

Current workaround route:

codex/gpt-5.5
Fallback: google/gemini-3.1-pro-preview
Runtime: OpenAI Codex

Provider / routing chain

Telegram topic -> main agent -> OpenAI Codex runtime/OAuth.

Before workaround the selected candidate was openai/gpt-5.5; after workaround active provider is codex with model gpt-5.5.

Additional provider/model setup details

Current live workaround config excerpt:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "codex/gpt-5.5",
        "fallbacks": ["google/gemini-3.1-pro-preview"]
      },
      "models": {
        "codex/gpt-5.5": {
          "alias": "codex",
          "agentRuntime": { "id": "codex" }
        }
      }
    }
  }
}

Logs, screenshots, and evidence

Relevant release/PR context found while triaging:

• #78899 says openai/* is the public OpenAI model route and openai-codex remains the auth/profile provider for ChatGPT/Codex OAuth.
• #79741 restored /status Codex 5h/week usage for OpenAI models running through the Codex harness by mapping status usage to openai-codex.
• #87252, included before/around 2026.5.27, made live-switch comparison tolerate runtime openai-codex/gpt-5.5 after persisted openai/gpt-5.5.
• #87439, included in 2026.5.27, changed Codex runtime model resolution to resolve Codex-owned OpenAI models through the runtime provider first.

This may mean the 5.27 provider behavior is intentional, but the live result was surprising: the canonical openai/gpt-5.5 route failed outright with a harness support error, and the working codex/gpt-5.5 workaround lost Telegram /status usage.

Source-level clue from 2026.5.27:

src/status/status-text.ts:
  resolveStatusRuntimeProvider maps harness=codex + provider=openai -> openai-codex
  currentUsageProvider = resolveUsageProviderId(activeStatusProvider) ?? resolveUsageProviderId(activeProvider)

src/infra/provider-usage.shared.ts:
  usageProviders includes openai-codex but not codex
  resolveUsageProviderId(provider) returns undefined for codex

So if active provider becomes codex, Telegram /status appears to have no usage provider to query, even though Codex usage retrieval works.

Related but not identical existing issues:

• #87436 covers openai-codex leaking into session route state after doctor repair.
• #87877 covers openai-codex persisted as session modelProvider causing recurring doctor warnings.
• This report is about a 2026.5.27 live operator path where openai/gpt-5.5 failed with Codex harness support errors, the live workaround was to switch to codex/gpt-5.5, and Telegram /status then lost usage display.

Impact and severity

Affected: at least one live Telegram-routed VPS running 2026.5.27 stable with OpenAI Codex OAuth/runtime.

Severity: Medium. The agent can be kept working with a config workaround, but the primary OpenAI route unexpectedly fell through to Gemini and /status lost an important operator signal for Codex quota usage.

Frequency: The harness rejection happened repeatedly on the live gateway after upgrade until the route was changed.

Consequence: Operator-visible fallback to Gemini, confusion about whether codex/gpt-5.5 is intended, and missing 5h/week usage in Telegram /status even though usage data is available.

Additional information

Question for maintainers: is codex/gpt-5.5 now intended to be a valid or preferred user-facing configured provider after 2026.5.27 / #87439, or should openai/gpt-5.5 remain the supported public route with Codex only as runtime/auth?

If codex/gpt-5.5 is intended/supported, status usage probably needs to treat codex as a Codex usage provider alias, or otherwise map it to openai-codex for quota display.

If codex/gpt-5.5 is not intended as the durable user-facing route, the more important bug is likely the 2026.5.27 harness selection/resolution path that rejected openai/gpt-5.5 with provider is not one of: codex.