openclaw - 💡(How to fix) Fix [Bug]: Switching main chat to Ollama/Gemma leaves Codex runtime active and fails before reply

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.5.7, switching the main dashboard chat/session model from gpt-5.5 to an Ollama/Gemma model makes the session show gemma4:31b, but the run still goes through the Codex app-server harness/runtime path. The next reply fails before producing a response because the Codex runtime rejects the Ollama auth profile.

This presents to the user as both dashboard chat and Telegram not responding, even though the gateway, webchat websocket, and Telegram provider are healthy.

Steps to reproduce

1. Run OpenClaw 2026.5.7 with default agent runtime configured as Codex:

{
  "agents": {
    "defaults": {
      "agentRuntime": { "id": "codex" },
      "model": { "primary": "gpt-5.5" }
    }
  }
}

1. Have Ollama auth/profile and Ollama models available, including gemma4:31b.
2. In the OpenClaw dashboard chat, switch the main session model to gemma4:31b.
3. Send a message in dashboard chat.
4. Observe that no assistant reply is produced.

Expected behavior

OpenClaw should not silently allow an incompatible runtime/model/auth combination.

One of these would be expected:

• switching to an Ollama model should route the session through an Ollama/PI-compatible runtime instead of the Codex app-server harness;
• or the UI should block the selection and explain that the current Codex runtime only supports openai-codex/supported Codex auth profiles;
• or the chat should surface a clear actionable error instead of appearing to hang/not respond.

Actual behavior

The UI/session state reports the main session model as gemma4:31b, but the reply fails before response with a Codex app-server auth-profile error:

Embedded agent failed before reply: Codex app-server auth profile "ollama:default" must belong to provider "openai-codex" or a supported alias.

From openclaw status after the manual switch:

agent:main:main     direct     gemma4:31b     OpenClaw Pi Default

But the persistent default config still has:

"agents": {
  "defaults": {
    "agentRuntime": { "id": "codex" },
    "model": { "primary": "gpt-5.5" }
  }
}

Gateway/webchat/Telegram were otherwise healthy:

[ws] webchat connected ... client=openclaw-control-ui webchat vcontrol-ui
[ws] ⇄ res ✓ health
[ws] ⇄ res ✓ models.list
[ws] ⇄ res ✓ sessions.list
[telegram] [default] starting provider (@agentkomersbot)

OpenClaw version

2026.5.7 (eeef486)

Operating system

macOS 26.4.1 (arm64)

Install method

Homebrew/global install, running as LaunchAgent gateway service

Model

Session-switched model: gemma4:31b

Configured default model: gpt-5.5

Provider / routing chain

Dashboard chat / main agent -> session model override gemma4:31b -> Ollama auth profile ollama:default -> still rejected by Codex app-server runtime/auth validation

Additional provider/model setup details

Relevant auth profiles exist:

openai-codex:default [openai-codex/oauth]
ollama:default [ollama/api_key]

The issue is not that the dashboard or Telegram transport is down. The issue is that a model switch to Ollama/Gemma can leave the session in a runtime/auth path that cannot use Ollama.

Logs, screenshots, and evidence

Sanitized gateway error excerpt:

2026-05-09T11:44:57.643-07:00 [agent/embedded] workspace bootstrap file MEMORY.md is 14988 chars (limit 12000); truncating in injected context
2026-05-09T11:44:58.102-07:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
2026-05-09T11:44:58.103-07:00 [diagnostic] lane task error: lane=main durationMs=1396 error="Error: Codex app-server auth profile \"ollama:default\" must belong to provider \"openai-codex\" or a supported alias."
2026-05-09T11:44:58.103-07:00 [diagnostic] lane task error: lane=session:agent:main:main durationMs=1398 error="Error: Codex app-server auth profile \"ollama:default\" must belong to provider \"openai-codex\" or a supported alias."
Embedded agent failed before reply: Codex app-server auth profile "ollama:default" must belong to provider "openai-codex" or a supported alias.

Earlier in the same incident, the primary/default OpenAI model was unusable due quota:

FailoverError: You exceeded your current quota...

That led to manually switching to gemma4:31b; the issue reported here is the subsequent runtime/auth mismatch after the switch.

Impact and severity

Affected: users who have agentRuntime.id = "codex" and try to recover from OpenAI/Codex quota/auth problems by switching the dashboard/main session to an Ollama model.

Severity: high for affected users. Both dashboard chat and Telegram can appear non-responsive even though the transports are healthy.

Frequency: reproduced on the main session after switching to gemma4:31b.

Additional information

This appears related in shape to Codex harness runtime/fallback routing issues such as #75739, but this report is specifically about a user-visible dashboard/session model switch allowing an incompatible Codex-runtime + Ollama-auth combination and then failing before reply.

A helpful fix might be to make model switching runtime-aware, or to validate model/provider compatibility against the active agent runtime before accepting the switch.