Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The chat UI model dropdown can show codex/gpt-5.5 as selected while the active session is actually using the default local model, in my case ollama/qwen3.5:9b.

This makes it difficult to tell which model is really being used. The only reliable workaround I have found is to manually run /model codex:gpt-5.5, even though the dropdown already appears to have that model selected.

Steps to reproduce

1. Configure OpenClaw with a local model as the primary/default model, e.g. ollama/qwen3.5:9b.
2. In the web chat/Main Session UI, select codex/gpt-5.5 from the model dropdown.
3. Continue using the session or return to the session later or even logout and log back in.
4. Observe that the dropdown still shows codex/gpt-5.5.
5. Check the actual runtime model by using /model or by observing behavior/logs.
6. The active model may be ollama/qwen3.5:9b even though the dropdown still says codex/gpt-5.5.

Expected behavior

The UI dropdown should reflect the actual active model for the session.

If OpenClaw intentionally falls back or “drifts” to the default/primary model, the UI should update to show the effective model, or clearly display both:

• selected/preferred model
• effective/runtime model

For example: codex/gpt-5.5 selected, currently using ollama/qwen3.5:9b.

Or, it should only change if the user changes the selected model in the chat drop down box for that specific session.

Actual behavior

The dropdown can continue showing codex/gpt-5.5 while the session is actually using ollama/qwen3.5:9b.

This creates a misleading UI state. Since the dropdown already appears correct, the user has no obvious way to fix it except manually running /model codex:gpt-5.5.

OpenClaw version

2026.6.6

Operating system

ubuntu 24.04 64bit

Install method

No response

Model

Configured/default primary: ollama/qwen3.5:9b Expected selected chat model: codex/gpt-5.5 Actual observed runtime model: ollama/qwen3.5:9b

Provider / routing chain

Local Ollama primary/default, Codex/OpenAI model selected in chat UI.

Additional provider/model setup details

I also saw a related case with a weekly cron job where healthcheck:security-audit had drifted back to ollama/qwen3.5:9b even though that task needs codex/gpt-5.5 for reliable tool-heavy execution. That was fixed by explicitly setting the cron model override:

openclaw cron edit <job-id> --model codex/gpt-5.5 --thinking off

The chat UI issue feels like the same class of problem: the effective runtime model can differ from the user-visible selected model, and the UI does not make that obvious.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response