Summary
A Telegram direct-chat session can remain pinned to a non-default model/provider even after /new and /reset, because the persisted session record keeps override fields instead of being fully cleared.
Observed behavior
Global default model was:
lmstudio/qwen/qwen3.6-35b-a3b
But the Telegram direct session kept resolving to:
- provider:
openai-codex
- model:
gpt-5.4
openclaw status showed the Telegram DM session still active on gpt-5.4 while the default remained qwen.
Persisted session key:
agent:main:telegram:direct:6761477233
Persisted session record contained these fields:
modelOverride: "gpt-5.4"
providerOverride: "openai-codex"
authProfileOverride: "openai-codex:..."
authProfileOverrideSource: "auto"
Why this looks like a bug
Running /new or /reset did not return the Telegram DM to the configured default model. The session-specific overrides survived and continued to win resolution.
That makes /new and /reset feel incomplete for channel-bound sessions, especially when the override source is auto rather than an explicit user-set override.
Reproduction sketch
- Configure default model to something non-Codex, e.g.
lmstudio/qwen/qwen3.6-35b-a3b.
- End up with a Telegram direct session that acquires an auto-created auth/model/provider override to Codex GPT-5.4.
- Run
/new or /reset in that Telegram DM.
- Check
openclaw status or session storage.
- The Telegram session still resolves to GPT-5.4 instead of the default model.
Evidence from persisted session storage
The session entry in ~/.openclaw/agents/main/sessions/sessions.json for the Telegram DM still contained the override fields after reset.
Manually deleting that single session entry made the Telegram session disappear from the active session list, which strongly suggests the sticky state lived in persisted session storage rather than runtime-only resolution.
Expected behavior
One of these should happen:
/reset and probably /new should clear session-scoped modelOverride, providerOverride, and auto-created authProfileOverride for the current chat/session, or
- there should be a dedicated command that fully clears session resolution state for the current chat, including auto-created auth/profile/provider pins.
Notes
This was observed on a Telegram direct chat session, but the underlying bug may affect any persisted channel-bound session key where authProfileOverrideSource is auto.
Summary
A Telegram direct-chat session can remain pinned to a non-default model/provider even after
/newand/reset, because the persisted session record keeps override fields instead of being fully cleared.Observed behavior
Global default model was:
lmstudio/qwen/qwen3.6-35b-a3bBut the Telegram direct session kept resolving to:
openai-codexgpt-5.4openclaw statusshowed the Telegram DM session still active ongpt-5.4while the default remained qwen.Persisted session key:
agent:main:telegram:direct:6761477233Persisted session record contained these fields:
modelOverride: "gpt-5.4"providerOverride: "openai-codex"authProfileOverride: "openai-codex:..."authProfileOverrideSource: "auto"Why this looks like a bug
Running
/newor/resetdid not return the Telegram DM to the configured default model. The session-specific overrides survived and continued to win resolution.That makes
/newand/resetfeel incomplete for channel-bound sessions, especially when the override source isautorather than an explicit user-set override.Reproduction sketch
lmstudio/qwen/qwen3.6-35b-a3b./newor/resetin that Telegram DM.openclaw statusor session storage.Evidence from persisted session storage
The session entry in
~/.openclaw/agents/main/sessions/sessions.jsonfor the Telegram DM still contained the override fields after reset.Manually deleting that single session entry made the Telegram session disappear from the active session list, which strongly suggests the sticky state lived in persisted session storage rather than runtime-only resolution.
Expected behavior
One of these should happen:
/resetand probably/newshould clear session-scopedmodelOverride,providerOverride, and auto-createdauthProfileOverridefor the current chat/session, orNotes
This was observed on a Telegram direct chat session, but the underlying bug may affect any persisted channel-bound session key where
authProfileOverrideSourceisauto.