Context Window Reattaches to Wrong Conversation After Power Loss

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After a power outage interrupted a Claude Code VS Code session, the session resumed but reattached to a completely different point in the conversation history. The context window shows a different usage percentage and the model operates from a stale timeline, unable to process new user messages despite acknowledging them momentarily.

Context didn't shrink — it shifted to a different timeline: Going from 82% to 62% used is not compaction. If context had compacted, the model would still be at the same point in the conversation with a compressed history behind it. Instead, the model resumed at a completely different point in the conversation — hundreds of builds behind the actual state — even though the JSONL transcript is contiguous and contains the full correct history. The context window didn't roll back within the current session; it reattached to what appears to be an entirely older conversation state, as if it loaded a checkpoint from a different point in time.

The model is not ignoring instructions: It genuinely cannot see or retain the user's corrections. The stale context (~620K tokens of old-era conversation) statistically overwhelms the small number of recent corrective messages. This is not a behavior problem — it's a context poisoning problem.

JSONL continuity is intact: The JSONL file continued logging correctly throughout. The local transcript shows the real conversation. The problem is entirely in the API-side context state.

Potential cause: The power cut may have caused the Claude Code extension to reconnect to Anthropic's API with a corrupted or mismatched conversation ID, loading context from a different point in the conversation history. Alternatively, the extension may have attempted to rebuild context from the JSONL but selected the wrong portion.

What Should Happen?

Session resumes with the same context state (82% used), continuing from where the conversation left off. The model should be aware of the most recent work, not revert to a state from hundreds of builds prior.

Error Messages/Logs

Steps to Reproduce

1. Start a long-running Claude Code session with high context usage (~82% used, 18% remaining, ~200K+ lines in session JSONL, ~990MB file)
2. Power outage kills the VS Code process mid-conversation
3. Power is restored; VS Code and Claude Code extension restart
4. Resume the conversation in the same session

Observed after resume:

• Context usage shifted from 82% used (18% left) to 62% used (38% left) — this is NOT compaction. Nothing was compacted. The context reattached to a completely different point in the conversation timeline.
• Model resumed from a point approximately 240 builds behind the actual conversation state
• Model references work (e.g., a "button fix") that was resolved hundreds of builds ago
• User tells model it lost context due to the power outage; model acknowledges momentarily, then immediately reverts to stale context on the next response
• Model attempts to edit source files to "fix" issues that no longer exist based on stale context — user had to interrupt tool uses to prevent destructive changes
• No amount of user messages can correct the model's state; the stale context (~620K tokens) dominates every response
• Lines L201160–L201234 in the JSONL are entirely file-history-snapshot entries (~75 consecutive snapshots with no user/assistant messages) — appears to be the extension dumping state during power cut recovery

Example exchange:

• Model: "We're trying to fix the HD cover showing the wrong game after pressing Circle at root"
• User: "no we are not"
• Model: "I'm wrong. What are we doing? Tell me."
• User: "i said it just 5 messages back., hold on i think something is wrong, you got compacted/detached twice?"
• Model: "I don't remember you saying that. When did you say it?"

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code VS Code Extension (version unknown at time of incident)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Impact:

• User unable to use the session for any productive work
• Model attempts destructive code edits based on stale context (editing files to fix bugs that no longer exist)
• Tokens wasted on messages the model cannot retain
• The session handoff document (the exact thing being created to prevent context loss) was itself lost to the context corruption

To be absolutely clear: this is NOT compaction. Nothing was compacted. The context window did not shrink or compress the conversation. It reattached to a completely different point in the conversation history — approximately 240 builds behind the actual state — as if it loaded a checkpoint from a different point in time. Going from 82% used to 62% used is not something that can happen through normal compaction. The JSONL transcript is contiguous with no gaps. The problem is entirely in the API-side context state.

Workaround:

• Force /compact to crush the stale context and let recent messages dominate
• Or start a new session entirely with a recovery document

Suggested Investigation:

1. What happens to the API-side conversation state when the client disconnects abruptly?
2. Is it possible for the extension to reconnect to a different conversation turn or checkpoint?
3. Can the extension validate that the resumed context matches the most recent JSONL entries before continuing?
4. Should the extension detect a context usage decrease (which is impossible under normal operation) and warn the user?

Evidence from JSONL Transcript:

Before power cut:

• Working on the latest build in the active development branch
• Working on: session handoff templates, OSK cursor fix, license file, doc updates
• Context: 82% used, 18% remaining

After power cut:

• Model references old work involving a "Circle button fix" and source file edits — from approximately 240 builds prior to actual state
• Model could not retain any corrections from the user (see example exchange in Steps to Reproduce)

Flood of file-history-snapshots: Approximately 75 consecutive file-history-snapshot entries with no user/assistant messages between them appear at the point of power cut recovery — appears to be the VS Code extension dumping state during recovery.

---

Update: Root Cause Identified via JSONL Forensic Analysis

The Dormammu Bug

After extensive forensic analysis of the session JSONL, we identified the exact mechanism causing the context reattachment.

The Orphaned Leaf Node

Every single time the session broke and reconnected, it landed on the SAME message:

L181422 [assistant] uuid=b2b74b9c-578b-409e-87cc-15f36070f8d5
timestamp: 2026-03-28T03:25:33
content: "Waiting."
parent: dabcbb1a-c4a7-4f81-92c3-78ef9a5d6ac3

This message was followed by a file-history-snapshot flood (L181426+) from a PREVIOUS session interruption on March 28. The conversation continued on a new chain after that, but L181422 was never given a child in the legitimate chain. It became a permanent orphaned leaf node.

Five Reattachments to the Same Node

Five separate messages across multiple session breaks ALL pointed to b2b74b9c as their parent:

| Line | Timestamp | Event |
|------|-----------|-------|
| L201237 | 2026-04-05 02:15 | First power cut recovery |
| L201597 | 2026-04-05 02:22 | Second reconnect attempt |
| L202286 | 2026-04-05 03:12 | Third reconnect attempt |
| L202894 | 2026-04-05 03:12 | Fourth (duplicate UUID — same message written twice) |
| L203970 | 2026-04-05 08:15 | Fifth reconnect after second crash |

The reattachment is deterministic, not random. The same orphan gets picked every time because the tip-finding algorithm consistently selects it.

Why THIS Specific Message

Analysis of all 1,272 leaf nodes in the session revealed the mechanism:

1. L181422 ("Waiting.") was the last assistant message before a file-history-snapshot flood on March 28
2. The conversation continued on a NEW chain after the March 28 flood — L181422 was never linked as a parent by any legitimate subsequent message
3. L181422 became a permanent orphaned leaf — a dead branch tip with isSidechain: false
4. When the April 5 power cut triggered another snapshot flood, the real conversation chain broke
5. The tip-finder searched for the "latest" non-sidechain leaf node
6. L181422 was consistently selected as the reattach point because it was the most prominent orphaned leaf in the chain graph

The Chain Break Mechanism

Before power cut (correct chain):

L203400 [user] → L203401 [assistant] → L203404 [user] → L203406 [assistant] → ...
     All parentUuids correctly chained

After power cut:

L203405-L203969: ~550 file-history-snapshot entries (no UUID, no parentUuid, no timestamp)

L203970 [user] parentUuid = b2b74b9c-578b-409e-87cc-15f36070f8d5
                             ↑ This is L181422 from March 28!!
                             ↑ 22,000 lines and 8 days backward

The break point:

L203404 uuid=b9d66c8d  parent=6185d669  ← CORRECT (chains to L203401)
   ... 550 snapshots ...
L203970 uuid=0940cb9b  parent=b2b74b9c  ← BROKEN (chains to L181422, March 28)

Impact on Token Usage

The broken reattachment caused Claude Code to rebuild context from the March 28 branch:

{
  "cache_creation_input_tokens": 593461,
  "cache_read_input_tokens": 11276
}

593K tokens of WRONG context were created and billed. The user's recent corrective messages (11K tokens) were statistically overwhelmed by 593K tokens of stale context. The model could not process corrections — it acknowledged them momentarily then reverted to the stale state on every response.

The Fix We Verified

We deleted L181422 (the orphaned "Waiting." message) from the JSONL. On next session open:

• The tip-finder could no longer land on the March 28 orphan
• It selected a different leaf node from the build #856 era (closer to present, but still not #1039)
• After /compact, the model stabilized at build #856

This confirms the root cause: the tip-finder selects orphaned leaf nodes as reattach points. The fix is to filter the tip-finder to only consider user and assistant messages:

// Current (buggy):
let tip = findTip(messages.values(), (msg) => !msg.isSidechain);

// Fixed:
let tip = findTip(messages.values(), (msg) => 
  !msg.isSidechain && (msg.type === "user" || msg.type === "assistant")
);

Additional Finding: file-history-snapshot Entries

The file-history-snapshot entries that trigger the chain break have these properties:

• type: "file-history-snapshot"
• NO uuid field
• NO parentUuid field
• NO timestamp field
• isSidechain not set (defaults to false)

They are written in bulk during session open/close/crash (~50-100 at a time). Because they have no parentUuid, they don't participate in chain-walking. But their presence in the JSONL appears to interfere with the chain reconstruction logic, causing the next real message to be assigned a parentUuid pointing to an old orphaned branch instead of the correct predecessor.

Related Issues

• #33651 — Same root cause (progress messages), silent message loss
• #37437 — Same root cause (403 retry), one-line fix identified
• #40319 — Regression in v2.1.85 (progress entry elision), fix scripts available

All three issues describe the same fundamental bug: non-conversation entries (progress, file-history-snapshot) with isSidechain: false corrupt the parentUuid chain on session resume.

Forensic Tools Used

Analysis performed using custom JSONL forensics toolkit (clauder project):

• session_search_mcp.py — CLI search across session transcripts
• rebuild.py — Replay edit operations to reconstruct file states
• Direct JSONL parsing to trace UUID chains and identify orphaned nodes

// Filter tip-finder to only consider real conversation messages
let tip = findTip(messages.values(), (msg) => 
  !msg.isSidechain && (msg.type === "user" || msg.type === "assistant")
);

# Walk chain backward from k, keep last N entries
chain_uuids = set()
current_uuid = k  # last non-sidechain UUID
while current_uuid and current_uuid in uuid_map:
    chain_uuids.add(current_uuid)
    current_uuid = uuid_map[current_uuid].get('parentUuid')

# Keep last 1500 chain entries in file order
chain_entries = [e for e in entries if e.get('uuid') in chain_uuids]
kept = chain_entries[-1500:]

# Null the first entry's parentUuid to root the chain
kept[0]['parentUuid'] = None

# Write with compact JSON (no spaces) for oT1 compatibility
for entry in kept:
    f.write(json.dumps(entry, separators=(',', ':')) + '\n')