Cloud session resumes the pre-/clear conversation after idle wake-up (VM restart), context jumps and model continues old state

Status Open
Maintainer reply None cached
Activity 1 comment · opened Oct 2, 2026

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-/clear conversation 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-/clear conversation (id prefix e786a2e9, about 15% context). An incoming cross-session message woke it; the VM restarted and the resumed conversation was the earlier one (id prefix be1bf2a4, 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 /clear and the wake-up in case B; the context jump came purely from a different conversation being opened.

Why it matters

  • Work done after /clear is 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)

  1. In a cloud session with a long conversation, run /clear and continue working in the new conversation.
  2. Let the session go idle long enough for its VM to be recycled (observed: under ~10 minutes).
  3. Wake it — e.g. another session sends it a message with the Claude Code Remote MCP send_message, or the user returns to it.
  4. 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)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗