Skip to content

Telegram direct session survives /new and /reset with persisted model/provider/auth override #69301

@JuniorAgentOC

Description

@JuniorAgentOC

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

  1. Configure default model to something non-Codex, e.g. lmstudio/qwen/qwen3.6-35b-a3b.
  2. End up with a Telegram direct session that acquires an auto-created auth/model/provider override to Codex GPT-5.4.
  3. Run /new or /reset in that Telegram DM.
  4. Check openclaw status or session storage.
  5. 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:

  1. /reset and probably /new should clear session-scoped modelOverride, providerOverride, and auto-created authProfileOverride for the current chat/session, or
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions