openclaw - 💡(How to fix) Fix [Bug]: 2026.5.27 upgrade leaves stale Codex plugin providerIds, breaking openai/gpt-5.5 route and status usage workaround

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading a live Telegram-routed VPS from OpenClaw 2026.5.26 to 2026.5.27, the previously working openai/gpt-5.5 + OpenAI Codex runtime route drifted/fell back because the active managed @openclaw/codex plugin remained at 2026.5.6 and advertised only providerIds: ["codex"]; switching the config to codex/gpt-5.5 restored execution but dropped Codex 5h/week usage from Telegram /status.

This consolidates #88102 plus the follow-up evidence comments into one issue body.

Steps to reproduce

Observed live operator path:

1. Start from a known-good OpenClaw 2026.5.26 VPS with Telegram topic sessions using:
   • model: openai/gpt-5.5
   • auth: OpenAI Codex OAuth
   • runtime: OpenAI Codex
2. Confirm Telegram /status shows both the Codex runtime and Codex usage windows.
3. Upgrade the same VPS to OpenClaw 2026.5.27 stable.
4. Leave the agent configured on the previous canonical route, openai/gpt-5.5 with Codex runtime.
5. Send Telegram messages in the affected topic.
6. Observe either route/runtime drift to OpenClaw Pi Default, or gateway rejection/fallback from the canonical route.
7. Inspect the active Codex plugin registration with openclaw plugins inspect codex --runtime --json.
8. Work around the rejection by changing the configured route to codex/gpt-5.5 with agentRuntime.id = "codex".
9. Send Telegram /status again.

Expected behavior

OpenClaw upgrade/repair should preserve the supported public Codex-runtime route:

openai/gpt-5.5 + Runtime: OpenAI Codex

If a managed @openclaw/codex plugin is installed, upgrading OpenClaw should not leave an older plugin registration active if that plugin narrows the Codex harness provider set and breaks the canonical openai/gpt-5.5 route.

If codex/gpt-5.5 remains supported as a compatibility/workaround route, Telegram /status should still show Codex 5h/week usage, either by mapping active provider codex to openai-codex usage or by repairing/rendering the session back to canonical openai/* before status usage lookup.

Actual behavior

1. Known-good 2026.5.26 status

Operator screenshot evidence, redacted for auth email:

Known-good 2026.5.26 Telegram /status screenshot
- OpenClaw 2026.5.26 (0e30120)
- Model: openai/gpt-5.5
- Auth: oauth (openai-codex:<redacted>)
- Fallbacks: google/gemini-2.5-flash
- Usage line present: 5h and Week quota windows shown
- Execution: direct
- Runtime: OpenAI Codex

2. 2026.5.27 intermediate route/runtime drift

Operator screenshot evidence, redacted for auth email:

Intermediate 2026.5.27 Telegram /status screenshot after upgrade, before the final codex/gpt-5.5 workaround
- OpenClaw 2026.5.27 (0e30120)
- Model: openai/gpt-5.5
- Auth: oauth (openai-codex:<redacted>)
- Fallbacks: google/gemini-2.5-flash
- Usage line still present in this intermediate state
- Execution: direct
- Runtime: OpenClaw Pi Default

That 2026.5.27 screenshot is not the later codex/gpt-5.5 no-Usage state; it captures an earlier route/runtime drift. It still shows that the same user-facing openai/gpt-5.5 route that used Runtime: OpenAI Codex on 2026.5.26 was showing Runtime: OpenClaw Pi Default after the 2026.5.27 upgrade.

3. 2026.5.27 live gateway rejection/fallback

While openai/gpt-5.5 was still configured/allowed, the gateway repeatedly rejected the primary route and fell back:

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 appeared 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

4. Active plugin registration explains the mismatch

The installed OpenClaw core package is 2026.5.27 and its bundled harness supports all three providers:

$ openclaw --version
OpenClaw 2026.5.27 (27ae826)

$ command -v openclaw
/usr/bin/openclaw

$ readlink -f $(command -v openclaw)
/usr/lib/node_modules/openclaw/openclaw.mjs

// /usr/lib/node_modules/openclaw/dist/harness-CC_xiKdz.js
const DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set([
  "codex",
  "openai-codex",
  "openai"
]);

But the active Codex plugin registration is from a separate managed plugin under ~/.openclaw/npm, and it narrows provider ownership to only codex:

$ openclaw plugins inspect codex --runtime --json
{
  "plugin": {
    "id": "codex",
    "version": "2026.5.6",
    "packageName": "@openclaw/codex",
    "source": "/home/ubuntu/.openclaw/npm/node_modules/@openclaw/codex/dist/index.js",
    "origin": "global",
    "trustedOfficialInstall": true,
    "enabled": true,
    "status": "loaded",
    "providerIds": ["codex"],
    "agentHarnessIds": ["codex"]
  }
}

openclaw plugins list --json also reported stale registry metadata:

Persisted plugin registry metadata no longer matches plugin manifest or package files; using derived plugin index. Run `openclaw plugins registry --refresh` to update the persisted registry.

This makes the live error internally consistent: the core bundle supports openai, but the active plugin registration says the Codex harness only owns codex, so openai/gpt-5.5 can be rejected as provider is not one of: codex.

5. Config backup evidence confirms the route transition

The VPS config backups show the route before upgrade/workaround and the subsequent changes:

// ~/.openclaw/openclaw.json.pre-20260527-stable-upgrade-20260529-151832.bak
{
  "agents.defaults.model": {
    "primary": "openai/gpt-5.5",
    "fallbacks": ["google/gemini-2.5-flash"]
  },
  "agents.defaults.models keys": [
    "openai/gpt-5.5",
    "openai/gpt-5.4"
  ]
}

// ~/.openclaw/openclaw.json.pre-fix-codex-model-route-20260529-170244.bak
{
  "agents.defaults.model": {
    "primary": "openai/gpt-5.5",
    "fallbacks": ["google/gemini-2.5-flash"]
  },
  "agents.defaults.models keys": [
    "openai/gpt-5.5",
    "openai/gpt-5.4"
  ]
}

A temporary attempted workaround used openai-codex/gpt-5.5:

// ~/.openclaw/openclaw.json.pre-fix-codex-provider-no-gemini-fallback-20260529-170825.bak
{
  "agents.defaults.model": {
    "primary": "openai-codex/gpt-5.5",
    "fallbacks": ["google/gemini-2.5-flash"]
  },
  "agents.defaults.models keys": [
    "openai/gpt-5.5",
    "openai/gpt-5.4",
    "openai-codex/gpt-5.5",
    "openai-codex/gpt-5.4"
  ]
}

The current live workaround uses codex/gpt-5.5:

// ~/.openclaw/openclaw.json
{
  "agents.defaults.model": {
    "primary": "codex/gpt-5.5",
    "fallbacks": ["google/gemini-3.1-pro-preview"]
  },
  "agents.defaults.models keys": [
    "codex/gpt-5.5"
  ]
}

A direct live openclaw agent --model=openai/gpt-5.5 repro is now blocked earlier because the current workaround config only allows the codex/gpt-5.5 model override:

GatewayClientRequestError: Error: Model override "openai/gpt-5.5" is not allowed for agent "main".

The earlier gateway logs above were captured before that workaround, while openai/gpt-5.5 was still configured/allowed.

6. Workaround restores execution but drops Telegram status usage

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. The same VPS can still fetch Codex usage through CLI status, so usage retrieval itself is not broken:

$ 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

First bad observed version:

OpenClaw 2026.5.27 (27ae826)

Last known good observed version:

OpenClaw 2026.5.26 (0e30120)

Operating system

Ubuntu 24.04.3 LTS
aarch64
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

Known-good route:

openai/gpt-5.5
Runtime: OpenAI Codex

Intermediate bad/drifted status:

openai/gpt-5.5
Runtime: OpenClaw Pi Default

Current live workaround:

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.

The important split is:

• core OpenClaw package: 2026.5.27, bundled Codex harness supports codex, openai-codex, and openai
• active managed Codex plugin: @openclaw/codex 2026.5.6 from ~/.openclaw/npm, runtime metadata only advertises providerIds: ["codex"]

Additional provider/model setup details

Relevant source/release context:

• #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 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.

ClawSweeper correctly noted on #88102 that current source and the release-tag bundled harness support openai; the live packaged-runtime evidence above explains the mismatch by showing that the active managed plugin registration was older and narrower.

Logs, screenshots, and evidence

Status source-level clue for the usage part:

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.
• #88102 is the superseded first version of this report; this issue consolidates its body plus the later evidence comments.

Impact and severity

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

Severity: Medium/P1 candidate. The agent can be kept working with a config workaround, but the expected OpenAI Codex route unexpectedly drifted/fell through to Gemini or Pi Default, and the workaround loses an important quota signal in Telegram /status.

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

Consequence:

• live Telegram agent unexpectedly used Gemini fallback instead of the intended OpenAI Codex path
• status showed runtime drift from OpenAI Codex to OpenClaw Pi Default after upgrade
• current workaround uses codex/gpt-5.5, but Telegram /status no longer shows 5h/week Codex usage
• operators cannot easily tell whether they are on the intended public route or a compatibility route

Additional information

This seems to need two fix/decision points:

1. Upgrade/repair should not leave an older managed @openclaw/codex plugin registration active if it narrows the provider set and breaks the canonical openai/gpt-5.5 Codex runtime route.
2. If codex/gpt-5.5 remains a supported compatibility/workaround route, /status usage still needs to map active provider codex to Codex usage (openai-codex) or repair the route back to canonical openai/* before status rendering.

Question for maintainers: should codex/gpt-5.5 remain a valid configured model route, or should upgrade/doctor/plugin repair always converge back to openai/gpt-5.5 with Codex as the runtime/auth layer?