openclaw - 💡(How to fix) Fix [Bug]: Codex runtime accepts non-OpenAI model selection but routes it into Codex app-server and fails before PI fallback

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Yes

Summary

After doctor --fix migrates an install to agentRuntime.id: "codex" with openai/gpt-5.5, the UI/model picker can still select non-OpenAI providers such as minimax/* or anthropic/*, but turns are routed into the Codex app-server and fail before reply with Model provider ... not found instead of using PI/provider routing or rejecting the incompatible selection up front.

One release-blocking edge case: after migration to the Codex runtime, non-OpenAI providers such as MiniMax/Anthropic can still appear selectable or usable as fallbacks, but the Codex harness receives them and fails with Model provider ... not found instead of routing through PI. The fix should either make auto provider-aware at invocation time or prevent incompatible provider routes from being selected/fallbacked under agentRuntime.id: "codex".

Steps to reproduce

1. Run OpenClaw 2026.5.7 with the Codex harness/plugin available.
2. Start from a working legacy Codex OAuth route such as openai-codex/gpt-5.5.
3. Run openclaw doctor --fix and restart the pod/gateway if needed so the Codex harness registers.
4. Confirm defaults/main agent use agentRuntime.id: "codex" with primary model openai/gpt-5.5.
5. Configure or expose a non-OpenAI provider model such as minimax/MiniMax-M2.7 or anthropic/*.
6. Select minimax/MiniMax-M2.7 directly in the Control UI/model selector.
7. Send a normal agent message.

Expected behavior

OpenClaw should not send non-Codex provider routes into the Codex app-server as if the Codex harness can run them.

Expected acceptable outcomes:

• The model selector should prevent selecting incompatible non-OpenAI providers while the active runtime is codex; or
• OpenClaw should switch the turn to the embedded PI/provider runtime for non-Codex providers; or
• OpenClaw should fail fast with a clear validation error explaining that agentRuntime.id: "codex" only supports Codex/OpenAI-compatible routes.

Actual behavior

OpenClaw should not send non-Codex provider routes into the Codex app-server as if the Codex harness can run them.

Expected acceptable outcomes:

• The model selector should prevent selecting incompatible non-OpenAI providers while the active runtime is codex; or
• OpenClaw should switch the turn to the embedded PI/provider runtime for non-Codex providers; or
• OpenClaw should fail fast with a clear validation error explaining that agentRuntime.id: "codex" only supports Codex/OpenAI-compatible routes.

Actual behavior

The non-OpenAI provider can be selected, but the turn fails before reply. With active-memory disabled, direct selection of minimax/MiniMax-M2.7 still produced:

CodexAppServerRpcError: failed to load configuration: Model provider `minimax` not found

Gateway logs also emitted:

Codex agent harness failed; not falling back to embedded PI backend

The same failure shape was observed for anthropic earlier:

CodexAppServerRpcError: failed to load configuration: Model provider `anthropic` not found

This confirms the failure is not limited to fallback selection and is not caused by active-memory pre-prompt behavior. Direct MiniMax selection is routed into the Codex harness and dies before PI/provider fallback can handle it.

OpenClaw version

2026.5.7 (main)

Operating system

Debian GNU/Linux 12 (bookworm)"

Install method

docker

Model

openai/gpt-5.5 minimax/Minimax-2.7

Provider / routing chain

openclaw -> ocp egress -> openai/minimax

Additional provider/model setup details

Working baseline after migration:

openai/gpt-5.5 with agentRuntime.id "codex"

Failing direct selection:

minimax/MiniMax-M2.7 with agentRuntime.id "codex"

Related observed failing provider:

anthropic/* with agentRuntime.id "codex"

Before the migration, the install used working Codex OAuth through an openai-codex:<redacted> auth profile and model refs like:

openai-codex/gpt-5.5

After doctor --fix and restart, live config/session status showed defaults/main/st-agent migrated to:

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

minimax was configured as a provider via ${MINIMAX_TOKEN} and appeared in the model catalog:

minimax/MiniMax-M2.7
minimax/MiniMax-M2.7-highspeed

The safe local posture is currently: keep Codex-runtime sessions on openai/* models only. Non-Codex providers require changing the runtime away from codex or an upstream provider-aware bridge/fallback fix.

Logs, screenshots, and evidence

# After doctor migration and restart:
# defaults/main/st-agent use agentRuntime.id: "codex" with openai/gpt-5.5.
# session_status reports Runtime: OpenAI Codex.

# Direct MiniMax selection with active-memory disabled:
CodexAppServerRpcError: failed to load configuration: Model provider `minimax` not found
Codex agent harness failed; not falling back to embedded PI backend

# Earlier same-shape provider mismatch:
CodexAppServerRpcError: failed to load configuration: Model provider `anthropic` not found
Codex agent harness failed; not falling back to embedded PI backend


The active-memory plugin was disabled before the direct MiniMax test, and gateway restart logs showed the active plugin set did not include `active-memory`, so the failure was isolated from that pre-prompt hook.

Impact and severity

Affected: users migrated to agentRuntime.id: "codex" who also have non-OpenAI providers configured or visible as selectable/fallback models.

Severity: High for affected sessions because the selected model route fails before reply.

Frequency: Observed every time for the tested direct MiniMax selection after migration; same failure shape was observed for Anthropic.

Consequence: Users can select a visible model that cannot run under the current runtime, leading to a pre-reply harness failure. This is especially confusing after doctor --fix, because the system appears migrated and healthy on the openai/gpt-5.5 Codex path.

Additional information

This appears related to earlier Codex-harness provider/fallback routing issues, especially:

• #75739, where non-Codex fallbacks were still routed through the Codex harness.
• #78499, where doctor --fix rewrote Codex runtime model refs to openai/* and caused auth-profile selection issues.
• #78609, where model/runtime migration and stale session/task state contributed to silent channel failures.

The current report is a narrower 2026.5.7 repro: after the migration path is otherwise healthy for openai/gpt-5.5 with the Codex runtime, directly selecting minimax/MiniMax-M2.7 still routes into Codex app-server and fails with Model provider \minimax` not found`.

Follow-up/nice-to-have: auto appears to route provider/model switches to a compatible runtime correctly, so the immediate failure mode is mainly stale or explicit codex runtime state. Longer term, runtime affinity probably belongs in the model catalog and/or user configured provider/model level config with auto using that as the default dispatch rule. That would make model selection, UI disabling, chat commands, and fallback validation all derive from one source of truth instead of each surface guessing compatibility independently.