You edit the config file. You change the default model. You restart the gateway. You send a message.
Nothing changed.
You stare at /status. It's still using the old model. You restart again. Same thing. You start questioning your sanity.
This is the ghost config problem, and it just showed up as openclaw/openclaw#51251.
What's happening
You're running an AI agent on OpenClaw. At some point, you used /model to switch to a different model for a session. Later, you change your default model in openclaw.json, restart the gateway, and expect every session to pick up the new default.
But they don't. Because that /model command wrote a modelOverride into the session store. And that override survives gateway restarts. And it has higher precedence than your config default.
Session modelOverride → wins
Config default model → ignored
The config file says one thing. The session does another. And there's no indication that an override exists.
Why this is worse than a regular bug
Most bugs crash or throw errors. This one works perfectly — just with the wrong model. Your agent responds, everything looks fine. You just happen to be burning tokens on a model you thought you'd switched away from.
It's the software equivalent of changing the thermostat but having a space heater running under your desk that you forgot about.
The deeper pattern: session state vs config state
This is a common pattern in long-running agent systems. You have two sources of truth:
- Config files — what the operator intends
- Session state — what the system learned from runtime interactions
In a stateless system, config wins always. But AI agent sessions are inherently stateful — they accumulate context, preferences, overrides. That statefulness is a feature.
The problem is when state outlives its context. That /model override made sense during testing three days ago. It makes zero sense after a config change and gateway restart. But nobody told the session store that.
The precedence problem
OpenClaw's model resolution:
session override > agent config > global config > defaults
Each layer makes sense individually. The issue is that session overrides are persistent and invisible. You can't see them from the config. You can't clear them in bulk.
What should happen instead
1. Clear overrides on gateway restart — Nuclear option. When gateway restarts, wipe session model overrides.
2. Show overrides in /status — Make the ghost visible. If a session has an active override, /status should show it alongside the config default.
3. Add /model reset — Let users explicitly clear the session override and fall back to config default.
4. Timestamp overrides and expire them — If an override predates the last config change, automatically expire it. Smartest solution, most complex.
The broader lesson
If you're building an agent system with layered configuration:
Every piece of persisted state needs a visibility mechanism and an expiry strategy.
It's not enough to save state. You need to answer:
- Can the operator see that this state exists?
- Can they clear it without destroying everything else?
- Does it expire when the context that created it is gone?
Session state that's invisible, immortal, and high-precedence is a recipe for ghost configs. And ghost configs are the kind of bug that makes you restart your laptop three times before realizing the problem is in a JSON file you forgot existed.
Found via openclaw/openclaw#51251. Also related: #51209 — fallback chains not cascading on provider errors, another case where runtime state doesn't behave the way config implies.
Top comments (0)