Skip to content

[Bug]: doctor --fix rewrites Codex runtime model refs to openai/* and breaks Codex auth profile selection #78491

@rodrigolourencofarinha

Description

@rodrigolourencofarinha

Bug type

CLI/config migration (openclaw doctor --fix)

Beta release blocker

No

Summary

After openclaw doctor --fix on OpenClaw 2026.5.5, agents using agentRuntime.id: "codex" were configured with openai/gpt-5.5, and Telegram turns failed because the Codex app-server tried to use openai:default instead of an openai-codex auth profile.

Steps to reproduce

  1. Use OpenClaw 2026.5.5 with the Codex plugin installed/enabled and agents using agentRuntime.id: "codex".
  2. Run openclaw doctor --fix.
  3. Restart the gateway.
  4. Send /new to a Telegram bot account.
  5. Send a normal Telegram message to the same bot.

Expected behavior

A normal Telegram message after /new should complete an agent turn. This was observed after manually setting the agents back to codex/gpt-5.5: the Claw Telegram session returned OpenClaw repair OK with deliverySucceeded: true, and a Murphy probe returned OK through provider: codex, model: gpt-5.5, agentHarnessId: codex.

Actual behavior

/new succeeded, but normal Telegram messages failed with the user-visible reply:

Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

Gateway logs showed:

2026-05-06T10:22:27.131-03:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
2026-05-06T10:22:27.132-03:00 [diagnostic] lane task error: lane=main durationMs=1175 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-05-06T10:22:27.132-03:00 [diagnostic] lane task error: lane=session:agent:main:telegram:direct:<redacted> durationMs=1176 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."

The same error was observed for another Telegram agent session:

2026-05-06T10:22:28.400-03:00 [diagnostic] lane task error: lane=session:agent:murphy:telegram:direct:<redacted> durationMs=885 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."

OpenClaw version

OpenClaw 2026.5.5 (b1abf9d)

Codex plugin inspected after repair: @openclaw/codex 2026.5.5.

Operating system

macOS 26.4.1 arm64, Node 25.9.0.

Install method

Gateway launched as a LaunchAgent:

/opt/homebrew/opt/node/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789

openclaw status --deep reported channel stable, gateway reachable at ws://127.0.0.1:18789, and update status pnpm · up to date · npm latest 2026.5.5.

Model

Failing path after doctor/config migration: openai/gpt-5.5 with agentRuntime.id: "codex".

Working workaround path: codex/gpt-5.5 with agentRuntime.id: "codex".

Provider / routing chain

Telegram DM -> local OpenClaw gateway 127.0.0.1:18789 -> configured agent -> agentRuntime.id: "codex" -> Codex app-server harness.

Observed failing auth selection: openai:default.

Observed successful workaround execution trace:

{
  "winnerProvider": "codex",
  "winnerModel": "gpt-5.5",
  "attempts": [
    {
      "provider": "codex",
      "model": "gpt-5.5",
      "result": "success",
      "stage": "assistant"
    }
  ],
  "fallbackUsed": false,
  "runner": "embedded"
}

Additional provider/model setup details

Auth profiles present, redacted:

anthropic:default -> provider anthropic
openai-codex:<redacted-email> -> provider openai-codex, mode oauth
openai:default -> provider openai, mode api_key

After the failure, the config showed all ten agents with:

{
  "model": { "primary": "openai/gpt-5.5" },
  "agentRuntime": { "id": "codex" }
}

Manual workaround applied:

agents.defaults.model.primary = codex/gpt-5.5
agents.list[*].model.primary = codex/gpt-5.5
plugins.entries.memory-core.* execution model refs = codex/gpt-5.5

After gateway restart, openclaw models list showed codex/gpt-5.5 as default,configured, and Telegram delivery succeeded.

Logs, screenshots, and evidence

openclaw doctor after the manual workaround still proposed migrating the working codex/gpt-5.5 refs:

Moved agents.defaults.model legacy runtime primary refs to canonical provider refs and selected codex runtime.
Moved agents.defaults.models legacy runtime keys to canonical provider keys.
Moved agents.list.main.model legacy runtime primary refs to canonical provider refs and selected codex runtime.
...
Run "openclaw doctor --fix" to apply these changes.

The installed OpenClaw migration code maps legacy provider codex to provider openai with runtime codex:

{
  legacyProvider: "codex",
  provider: "openai",
  runtime: "codex",
  cli: false
}

The installed Codex plugin harness only supports provider codex by default:

const DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex"]);

The installed Codex plugin provider catalog uses CODEX_PROVIDER_ID = "codex".

Impact and severity

Affected users/systems/channels: observed on Telegram DM sessions for the default Claw agent and Murphy; the config showed the same openai/gpt-5.5 + agentRuntime.id: "codex" pairing for all ten configured agents.

Severity: blocks Telegram agent replies.

Frequency: observed on normal Telegram messages after /new at 10:22 and 10:23 on 2026-05-06.

Consequence: Telegram users receive the generic failure reply instead of an agent response.

Additional information

Before this issue was isolated, a stale Codex plugin install was also observed: host OpenClaw was 2026.5.5, installed @openclaw/codex was 2026.5.3, and openclaw plugins update codex reported it was up to date. For this report, the auth-profile failure above was reproduced/verified after installing @openclaw/codex@2026.5.5 and disabling a separate active-memory timeout, so the remaining grounded failure was the model/provider migration mismatch.

Do not include API keys, tokens, or passwords in follow-up diagnostics.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions