Cloud session resumes the pre-/clear conversation after idle wake-up (VM restart), context jumps and model continues old state
Summary
In Claude Code cloud sessions (claude.ai/code), after /clear is used to start a fresh conversation in the same session, the session can later come back up on the pre-/clear conversation instead of the current one. It happens when the idle session is woken again (its VM restarts and the conversation is resumed). The model then continues from the old, long transcript as if /clear had never happened.
What was observed (2026-10-02, KST, two different cloud sessions on one account)
- Session A: the pre-
/clearconversation was reopened three times — at 10:10, 11:09 and 16:07. The conversation reopened at 16:07 then went through auto-compaction at about 76% context. - Session B at 17:07: the session was idle on its post-
/clearconversation (id prefixe786a2e9, about 15% context). An incoming cross-session message woke it; the VM restarted and the resumed conversation was the earlier one (id prefixbe1bf2a4, about 710k tokens, 71–72% context). - The first turn after waking still reported 15% context (measured against the stale transcript); from the second turn on it reported 72%.
- The model believed it was still in the earlier phase of work and acted on that (it announced a hand-off that had already happened).
- No auto-compaction or user action occurred between the
/clearand the wake-up in case B; the context jump came purely from a different conversation being opened.
Why it matters
- Work done after
/clearis invisible to the resumed conversation, so the session repeats or contradicts it. - Context usage jumps from a small value to 70%+ without any new content, which then triggers compaction.
- Any incoming message to an idle cloud session can trigger this, so other sessions cannot safely message it.
Expected
After /clear, a later resume (including after a VM restart or a wake-up by an incoming message) should continue the post-/clear conversation.
Hypothesis (unverified)
/clear keeps the same session id and only creates a new conversation/transcript under it. If the resume path after a VM restart looks the conversation up by session id, it has more than one candidate and can pick the older one. This would also explain why the first turn's context figure is computed from one transcript and later turns from another.
Steps that led to it (not yet a minimal repro)
- In a cloud session with a long conversation, run
/clearand continue working in the new conversation. - Let the session go idle long enough for its VM to be recycled (observed: under ~10 minutes).
- Wake it — e.g. another session sends it a message with the Claude Code Remote MCP
send_message, or the user returns to it. - Sometimes the conversation that resumes is the one from before step 1.
Environment
- Claude Code cloud sessions (claude.ai/code), started from a GitHub repository, Linux container
- Observed by the cloud sessions themselves via their own session event listing; reported here from a local Claude Desktop session on the same account
- Possibly related: #98897 (cross-session messages between local and cloud sessions not reaching the conversation on the same day)
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗