Skip to content

[Bug]: openclaw doctor --fix rewrites openai-codex/* model refs to openai/* on 2026.5.4 → 2026.5.5 update, locking out ChatGPT-OAuth users #78407

Description

@100yenadmin

Summary

After updating from openclaw 2026.5.4 to 2026.5.5, the launchd-handoff restart automatically runs openclaw doctor --non-interactive --fix. The doctor migration mutates openclaw.json and rewrites every openai-codex/* model reference to openai/* across agents.defaults.modelOverride, per-agent modelOverride blocks, per-channel modelOverride blocks, and agents.modelCatalog. Users authenticated only via OpenAI Codex OAuth (i.e., a ChatGPT account, no OPENAI_API_KEY) are then locked out — every agent run fails on boot with:

[boot] agent run failed: No API key found for provider "openai".

openai-codex/gpt-5.4-pro is also lost entirely in the rewrite — there is no openai/gpt-5.4-pro in the catalog, so the model entry effectively disappears.

Environment

  • openclaw 2026.5.5 (fresh install via npm global), upgraded from 2026.5.4
  • macOS 14 (Darwin 25.4.0)
  • Auth profiles: openai-codex:<chatgpt-account> + anthropic:default. No openai:* profile.
  • Last-good auth-state.json:
    "lastGood": { "anthropic": "anthropic:default", "openai-codex": "openai-codex:<account>" }

Reproduction

  1. On 2026.5.4, configure agents.defaults.modelOverride:
    "modelOverride": {
      "primary": "openai-codex/gpt-5.5",
      "fallbacks": ["openai-codex/gpt-5.4", "openai-codex/gpt-5.4-mini"]
    }
    And agents.modelCatalog containing openai-codex/gpt-5.4, openai-codex/gpt-5.4-mini, openai-codex/gpt-5.4-pro, openai-codex/gpt-5.5, openai-codex/gpt-5.5-pro.
  2. Have only an openai-codex:* profile in ~/.openclaw/agents/<agent>/agent/auth-profiles.json — no openai:*.
  3. Update to 2026.5.5. The launchd post-update handler runs openclaw doctor --non-interactive --fix.
  4. Boot the gateway. Send any message in webchat to the affected agent.

Expected

Doctor migration leaves openai-codex/* refs alone (they are still valid model ids in 2026.5.5openclaw models list confirms openai-codex/gpt-5.5 is listed and configured with Auth: yes). At minimum, doctor should not rewrite a model ref to a provider for which the user has no auth profile.

Actual

Diff of openclaw.json immediately before/after the doctor --fix run (from ~/.openclaw/openclaw.json.bak.1~/.openclaw/openclaw.json.bak):

       "modelOverride": {
-        "fallbacks": [ "openai-codex/gpt-5.4", "openai-codex/gpt-5.4-mini" ],
-        "primary": "openai-codex/gpt-5.5"
+        "fallbacks": [ "openai/gpt-5.4", "openai/gpt-5.4-mini" ],
+        "primary": "openai/gpt-5.5"
       },

       "modelCatalog": {
-        "openai-codex/gpt-5.4": {},
-        "openai-codex/gpt-5.4-mini": {},
-        "openai-codex/gpt-5.4-pro": {},
-        "openai-codex/gpt-5.5": {},
-        "openai-codex/gpt-5.5-pro": {}
+        "openai/gpt-5.4": {},
+        "openai/gpt-5.4-mini": {},
+        "openai/gpt-5.4-pro": {},
+        "openai/gpt-5.5": {},
+        "openai/gpt-5.5-pro": {}
       }

The same rewrite occurs in 5 separate locations in the config (default + 3 per-agent/per-channel modelOverride blocks + the catalog). openai-codex/gpt-5.4-pro is renamed to openai/gpt-5.4-pro, which does not exist in the model catalog.

Evidence from logs

~/.openclaw/logs/config-audit.jsonl:

{"ts":"2026-05-06T09:38:10.210Z","argv":["...openclaw","doctor","--non-interactive","--fix"],
 "changedPathCount":57,"previousHash":"7c638e8a…","nextHash":"84d28f91…","result":"rename"}

~/.openclaw/logs/gateway.err.log (within seconds of the doctor run):

2026-05-06T16:38:31.510+07:00 [diagnostic] lane task error: lane=main durationMs=1224 error="FailoverError: No API key found for provider \"openai\". Auth store: …/agents/main/agent/auth-profiles.json …"
2026-05-06T16:38:31.518+07:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=auth next=none detail=No API key found for provider "openai". …
2026-05-06T16:38:31.569+07:00 [boot] agent run failed: No API key found for provider "openai". …

~/.openclaw/logs/gateway-restart.log:

[2026-05-06T09:38:22Z] openclaw restart attempt source=update target=ai.openclaw.gateway
[2026-05-06T09:38:22Z] openclaw restart done   source=update
[2026-05-06T09:45:09Z] openclaw restart attempt source=update target=ai.openclaw.gateway
[2026-05-06T09:45:10Z] openclaw restart done   source=update

The error is recoverable in user-facing terms — openai-provider-BVG8OXtu.js:225 even prints the right hint:

No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.5, or set OPENAI_API_KEY for direct OpenAI API access.

…but doctor is the thing producing the bad refs in the first place, so simply re-editing the config and restarting works only until the next doctor run.

Suspected location

dist/doctor-config-flow-D_wwaDIB.js:141:

const LEGACY_MODELS_ADD_CODEX_MODEL_IDS = new Set(["gpt-5.5", "gpt-5.5-pro"]);
function isLegacyModelsAddCodexMetadataModel(params) {
  // returns true for openai-codex/gpt-5.5 with the canonical reasoning/image/cost shape
}

The _ADD_CODEX_ naming suggests this branch is meant to add the -codex prefix, but the observed effect is the opposite (strip it). Either the call-site that consumes this set is inverted, or there is a sibling _REMOVE_CODEX_ migration acting on these model ids. The exact mutator is not in doctor-config-flow-D_wwaDIB.js directly; it is invoked from the broader doctor flow during --fix.

Workaround

  1. cp ~/.openclaw/openclaw.json.bak.1 ~/.openclaw/openclaw.json (the pre-doctor backup), or
  2. Manually re-prefix every openai/gpt-5.X* back to openai-codex/gpt-5.X* in modelOverride.{primary,fallbacks} and modelCatalog.
  3. Avoid running openclaw doctor --fix until this is patched.

Happy to attach the full pre/post openclaw.json diff or the redacted config-audit excerpt if useful.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

Priority

None yet

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions