When Active Session Ends: Why /new Creates Empty

When a session times out but /new is still called, OpenClaw’s session-memory hook often produces a bare-bones file - no conversation, just headers. This bug surfaces not from crashes, but from a mismatch: the hook assumes the session ID belongs to the old, timed-out session, yet passes a fresh session ID. Here’s the real catch: the fallback slug uses a timestamp-based filename (e.g., 2026-03-20-0126.md) instead of the session’s actual .jsonl file, and the previousSessionEntry is null. Users see no message traffic logged, yet a memory file is written - empty, unhelpful, and confusing. This isn’t a reset error but a context failure. To fix it, update the hook to recognize previous session IDs even when timed out, and ensure the memory handler resolves the correct session path. Related to similar /reset issues, this bug highlights how session state tracking can break silently. Next time, watch for empty memory files after timed-out sessions - your conversation history depends on it. Should /new on a stale session always restore the prior session’s text, not just reset a blank slate?

The core issue: /new uses a new session ID, not the stale one, so the hook fetches empty data. Fix: resolve previous session entry properly in context. Related issues #21382 and #8185 show this pattern repeats. The solution? Better session ID mapping in fallback logic.

Closing thought: in ephemeral chats, memory matters - even when it’s just a header. How often do you assume a session persists when it doesn’t?

• OpenClaw team