openclaw - 💡(How to fix) Fix /new and /reset slash commands rotate openclaw session but do not archive the LCM conversation [1 comments, 2 participants]

Summary

/new (and /reset) on Discord and Telegram channels rotates the openclaw session JSONL but does not archive the underlying LCM conversation. The same conversation_id keeps absorbing across "fresh" sessions, accumulating thousands of messages over hours/days. From a user perspective, "reset" doesn't actually reset — the next message inherits all prior LCM context, leading to context anchoring on stale topics, slow turns from huge cached prefixes, and eventually safeguard-triggered context-limit resets.

Concrete repro / evidence

In one of our channels (agent:main:discord:channel:1485749137319268487), the user issued /new four times today (2026-04-30). After each /new, openclaw rotated the session file and updated sessions.json correctly. But the LCM conversations.conversation_id=239 stayed active=1 the whole time and grew from a few hundred messages → 17,886 messages over 22 hours, because each new openclaw session was just updating the session_id pointer on the same conv row.

Effects users see:

• After /new, the bot still references topics from hours ago (LCM injects summarized context from the old conv into every new "fresh" prompt)
• Eventually hits the safeguard reset: "Context limit exceeded. I've reset our conversation"
• Per-turn cost balloons because LCM is injecting 70k-100k cached tokens of stale summaries

Why this is the load-bearing fix

The standard recovery recipe documented in our runbook is now a multi-step manual SQL update + file move + sessions.json edit:

1. UPDATE conversations SET active=0, archived_at=datetime('now'), session_key=session_key||':archived:'||strftime('%Y%m%d%H%M%S','now') WHERE conversation_id=N
2. Move <sid>.jsonl + .trajectory.jsonl + .trajectory-path.json aside
3. Edit sessions.json to delete sessionId / sessionFile for the channel's session_key

Step 1 (the SQL update) is the one that actually severs the LCM continuity. Steps 2-3 alone (which is what /new already does) leave LCM unchanged.

We've documented this and built a script (lcm-reset.sh) to do all three steps, but the right place for it is in /new itself — when a user explicitly asks to start fresh, they expect a true reset, not a session-file rotation.

Suggested fix

In the discord/telegram slash-command handler for /new (and /reset), after rotating the session JSONL, also:

UPDATE conversations
SET active = 0,
    archived_at = datetime('now'),
    session_key = session_key || ':archived:' || strftime('%Y%m%d%H%M%S','now')
WHERE session_key = ? AND active = 1;

The session_key uniquification is necessary to satisfy the existing unique index conversations_active_session_key_idx.

Archived LCM data remains fully searchable via lcm_grep, lcm_describe, lcm_expand_query with allowCrossConversation: true or explicit conversationId, so this is non-destructive — the bot can still recall prior context on demand even after reset.

Optional follow-on: keep current behavior available

If existing behavior is intentional for some users (rotate session but preserve LCM continuity), expose the new behavior as /new --hard or /reset --hard and keep /new rotating-only. Or wire it via a config flag at agents.defaults.commands.newResetsLcm: true.

Either way: the current default of "rotate session but silently leave LCM unchanged" is surprising and produces the symptoms above repeatedly.

Related

• We confirmed /lossless rotate is a deliberate "compact transcript while preserving LCM continuity" — that pattern has its place. The complaint is that /new and /reset advertise "fresh start" semantics but currently behave more like /lossless rotate from the user's perspective.
• The runbook entry "LCM survives openclaw session rotation" in [openclaw-meridian-loop-runbook.md] documents this discovery and the manual fix recipe that this issue would automate.

Environment

• openclaw 2026.4.26 (be8c246)
• Affects discord + telegram slash commands
• Reproduces with any channel session that has accumulated LCM history