Summary

/new can successfully create a fresh session, but that fresh session can later be abandoned if the session-routing mode changes (for example reverting from per-channel-peer back to unified), causing the conversation to resume on an older session with stale cached state.

Why this is a bug

From the operator's perspective, /new means "start fresh here."

In this case, /new did create a new Telegram-direct session, but later routing changes caused the same chat to resolve back onto an older unified session. That older session still carried stale cached metadata (skillsSnapshot), so /new did not actually deliver the expected clean-slate behavior.

Observed behavior

• /new created a fresh session:
  • session id: f07cc7f9-6b02-4bf0-8612-f9cf3d69eea8
  • session key: agent:main:telegram:direct:745400293
  • timestamp: 2026-03-14T22:00:59.609Z
• the new session got the normal startup injection (A new session was started via /new or /reset...)
• later that night, routing was reverted back to the unified model:
  • removed dmScope: "per-channel-peer"
  • removed hardcoded cron sessionKey: "agent:main:main" overrides
  • gateway restarted
• after that, the same Telegram DM conversation resumed on an older unified session instead of the fresh /new session:
  • active key became agent:main:main
  • session id: fa068c07-6045-4eb6-9cd7-2b487572ad82
• the older resumed session still had stale cached state and became the source of follow-on issues

Expected behavior

One of these should happen:

1. /new should remain authoritative for that conversation even if routing policy changes later, or
2. if routing policy changes invalidate the fresh session's lane, OpenClaw should explicitly migrate/rebind the fresh session to the new routing model, or
3. at minimum, the system should surface a warning that the /new session was superseded and the conversation resumed on an older session

Repro shape

1. Run with Telegram DM routing that creates a per-channel-peer direct session
2. Use /new in that DM
3. Confirm a fresh session is created
4. Change routing policy back to unified-session behavior
5. Restart gateway
6. Send another message in the same Telegram DM
7. Observe the conversation resolving back onto an older unified session instead of the /new session

Impact

• /new appears unreliable to operators
• clean-slate recovery after bugs/incidents can silently fail
• older cached session state can be resurrected unexpectedly
• debugging gets confusing because /new technically worked, but not durably

Potential fix directions

• bind /new to the surface/conversation more durably across routing-model transitions
• migrate freshly created sessions when routing policy changes
• add doctor/diagnostics for "fresh /new session was superseded by routing-model change"
• consider invalidating or quarantining older eligible sessions when /new was recently issued in the same conversation