Summary

Changing DM routing back to session.dmScope = "main" did not reconcile or retire old peer-keyed direct sessions on this machine.

That left multiple live direct-session identities coexisting, including the canonical main session and stale Telegram-peer-keyed direct sessions. In practice this created misleading "Telegram vs TUI are unsynced" symptoms until the stale session records were manually removed from the session store.

Environment

• OpenClaw: 2026.3.12
• OS: Linux x64
• Gateway mode: local
• Channel involved: Telegram DM + TUI/main

Relevant config

Live config during investigation (sanitized):

{
  "session": {
    "dmScope": "main",
    "mainKey": "main"
  }
}

Observed behavior

Even with session.dmScope = "main", the session store still contained both:

• canonical main direct session:
  • agent:main:main
• stale peer-keyed Telegram direct session:
  • agent:main:telegram:direct:TELEGRAM_USER_ID

At different points there were also other stale direct-ish leftovers, such as:

• an old Telegram slash session
• an old TUI-specific direct session

The key problem was that the stale peer-keyed Telegram direct session still existed after routing had supposedly returned to canonical main-session behavior.

Why this is a problem

From an operator perspective, this makes the system feel haunted:

• Telegram can correctly land in agent:main:main
• a stale peer-keyed direct session can still remain in the store with history
• TUI/session comparisons become ambiguous
• it is easy to conclude "Telegram and TUI are unsynced" when in reality a ghost session is still hanging around

Concrete evidence from this machine

During live investigation:

1. Current Telegram conversation was positively identified as agent:main:main.
2. A stale peer-keyed direct session still existed in the session store:
   • agent:main:telegram:direct:TELEGRAM_USER_ID
3. That stale session still had readable history.
4. Manual deletion of the stale peer-keyed session entry/file did not break current Telegram DM routing.
5. A fresh Telegram test message after deletion still landed in:
   • agent:main:main
6. The stale peer-keyed direct session did not get recreated immediately.

This strongly suggests the stale peer-keyed session had become leftover state rather than an actively required routing identity.

Manual workaround used

We had to manually clean the session store:

• backup sessions.json
• remove stale direct-session keys from ~/.openclaw/agents/main/sessions/sessions.json
• move the corresponding JSONL files aside
• verify fresh Telegram DM still attached to agent:main:main

After cleanup, only the intended main direct session remained for direct-chat use.

Expected behavior

When session.dmScope is changed back to main, OpenClaw should do one of the following:

1. automatically reconcile/retire stale peer-keyed direct DM sessions, or
2. clearly mark them as legacy/inactive so they do not continue to confuse operators, or
3. provide an official cleanup/migration command for collapsing old DM session identities safely.

Actual behavior

Stale peer-keyed direct sessions remain present and sufficiently "real" to confuse debugging, even after canonical DM routing is back on agent:main:main.

Impact

This caused substantial wasted debugging time because it made session continuity look broken or inconsistent across Telegram and TUI when the real issue was stale leftover session state.

Notes

This report is intentionally sanitized:

• Telegram user IDs redacted
• local usernames/paths minimized
• session/file UUIDs omitted

If maintainers want, I can provide a more structured sanitized before/after sessions.json shape as a follow-up.