Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When a provider is deleted from OpenClaw config, session-level provider/model overrides pointing to the deleted provider remain persisted in sessions.json. The gateway silently routes through the deleted provider with zero warning, zero log, zero doctor flag. Only recovery is manual sessions.json deletion + gateway restart.

Steps to reproduce

1. Configure OpenClaw with a provider (e.g. ollama-cloud) in openclaw.json
2. Set session-level model override to use that provider via session_status
3. Delete/remove the provider from openclaw.json config
4. Restart gateway
5. Observe sessions.json still contains override pointing to deleted provider
6. Send messages — gateway routes through deleted provider, not configured default
7. Try /model command — visible model changes but effective override persists
8. Try session_status model=default — only fixes current session
9. Try gateway restart — overrides survive in sessions.json

Expected behavior

1. Deleting a provider from config MUST invalidate all session overrides pointing to that provider
2. Gateway restart should re-validate all persisted session overrides against current config
3. doctor MUST flag sessions where effective provider differs from configured default, especially when effective provider is absent from config
4. Session overrides for non-existent providers MUST be treated as invalid and fall through to default
5. /model reset or openclaw sessions reset-model command should exist

Actual behavior

After deleting ollama-cloud provider from config on 2026-06-02, the session override ollama-cloud/deepseek-v4-pro:cloud remained persisted in sessions.json across BOTH WebChat and Telegram sessions for 2 days. The gateway silently continued routing requests through the deleted provider with ZERO indication — no log warning, no doctor flag, no error message.

Quota burned from 90% to 100% during this period.

Recovery failures:

• /model command: changed visible model, NOT effective session override
• session_status model=default: only cleared override for current session
• Gateway restart: did NOT clear sessions.json overrides

Only recovery: openclaw gateway stop → manually delete sessions.json → openclaw gateway start

OpenClaw version

2026.5.27

Operating system

Windows 11

Install method

npm global

Model

deepseek-v4-pro

Provider / routing chain

custom-api-deepseek-com/deepseek-v4-pro (configured), ollama-cloud/deepseek-v4-pro:cloud (deleted but persisted as session override)

Additional provider/model setup details

Config: custom-api-deepseek-com/deepseek-v4-pro as default model. Session override was set to ollama-cloud/deepseek-v4-pro:cloud via session_status. After ollama-cloud provider was removed from config, the override persisted in sessions.json across multiple sessions.

Logs, screenshots, and evidence

Gateway logs showed "Model Fallback" messages attempting to route through ollama-cloud. sessions.json contained entries with model override set to ollama-cloud/deepseek-v4-pro:cloud even after provider deletion.

Impact and severity

Affected: ALL active sessions (WebChat + Telegram) silently poisoned
Severity: CRITICAL — FINANCIAL DAMAGE RISK. If a pay-per-token provider is replaced with a cheaper one but the session override silently persists, user is billed for the expensive provider without knowing. Config says one thing, gateway does another.
Frequency: Always — triggers whenever a provider is deleted while session overrides that reference it exist
Consequence: Quota exhaustion (100% in our case), billing for unintended provider, ALL normal recovery commands fail, requires nuclear option (gateway stop + delete sessions.json + restart)

Additional information

This is NOT the same as issue #90462 (which is about LM Studio fallback trapping one topic). Our case is worse: the provider was COMPLETELY DELETED from config, yet the session override survived in sessions.json across MULTIPLE sessions simultaneously. Recovery required deleting the entire sessions.json file because no per-session reset command exists.

Related: #90462 (similar root cause, but fallback-only, single-session)

This exposes a billing integrity bug: gateway routes through providers absent from config.