[Bug]: Telegram /new -----Does not create new session ID -— context window fills indefinitely via scroll history.db

## QwenPaw Version V2.01

Description

The /new command is intended to start a fresh conversation, but in QwenPaw it only clears the in-memory context (state.context.clear()) without rotating the session ID. On Telegram, resolve_session_id() hardcodes telegram:{chat_id}, which never changes. This means:

- The scroll manager's history.db accumulates entries across what users perceive as separate conversations, all keyed to the same session ID
- The eviction index grows unbounded
- The context window fills up over time because the durable session state never actually resets

Users expect /new to give them a completely fresh start. It doesn't.

Steps to Reproduce

1. Connect QwenPaw to Telegram
2. Have a long conversation with the agent (enough to trigger scroll eviction into history.db)
3. Type /new — receive "New Conversation Started!" confirmation
4. Continue chatting — the context window fills up faster than expected because history.db still contains all entries from before /new
5. After enough /new cycles, the context window is dominated by stale history from previous "sessions"

Expected Behaviour

/new should rotate the session ID (e.g. telegram:{chat_id}:{timestamp}_{uuid}) so that:
- A fresh session file is created
- history.db entries from the old session are not loaded into the new one
- The scroll manager starts with a clean eviction index
- The channel's routing maps the chat to the new session ID

Actual Behaviour

/new clears state.context and saves to disk, but:

1. Session ID stays telegram:{chat_id} forever — resolve_session_id() in app/channels/telegram/channel.py:1546 is hardcoded
2. history.db retains all old entries keyed by the same session ID — ScrollContextManager in agents/context/scroll/manager.py never purges
3. Eviction index accumulates across /new boundaries — EvictionIndex persists in the session checkpoint
4. Context window fills as new messages compound with durably-stored old history

Relevant Code

Session ID resolution — app/channels/telegram/channel.py:1546:
Python


def resolve_session_id(self, sender_id, channel_meta=None):
meta = channel_meta or {}
chat_id = meta.get("chat_id")
if chat_id:
return f"telegram:{chat_id}" # Always the same
return f"telegram:{sender_id}"

/new handler — agents/command_handler.py:569:
Python


async def _process_new(self, messages, _args=""):
await self._reset_modes()
# ... summarize, clear summary ...
await self._persist_and_clear() # Only clears state.context
return "New Conversation Started!"

_persist_and_clear — agents/command_handler.py:621:
Python


async def _persist_and_clear(self):
state = self._state
if state.context and self._offloader is not None:
await self._offloader.offload_context(...)
state.context.clear() # ← This is ALL it does

Scroll checkpoint — runtime/builtin_commands.py:374:
Python


def _resolve_scroll_block(*, updated, context_empty, existing):
if context_empty:
return None # Checkpoint dropped, but history.db entries persist
return existing

Comparison with Hermes Agent

Hermes solves this correctly. Its SessionStore.reset_session() (in gateway/session.py:3202) generates a new session ID:

Python


session_id = f"{now.strftime('%Y%m%d_%H%M%S')}_{uuid.uuid4().hex[:8]}"

And rewrites the Telegram topic binding so the next inbound message routes to the new session. QwenPaw has no equivalent mechanism.

Suggested Fix

Either:

A. Rotate the session ID (proper fix): Generate a new session ID on /new, save state under the new ID, and update the channel's session mapping so the next message routes correctly. This matches Hermes' behaviour.

B. Purge scroll history (practical workaround): After /new clears context, call HistoryStore.purge(session_id=...) and reset the EvictionIndex so the scroll manager starts clean under the same session ID. Simpler but less clean — the session file still accumulates metadata.