Beware: Claude Code Silently Drops Your Work

You hit Esc to interrupt the agent mid-turn to ask a quick question. Normal, right? You resume, ask “what did we just decide,” and the agent tells you — with full confidence — that no such planning session ever happened. It even says there were zero scoping questions in your session. That’s not you losing your mind. That’s a real, reproducible Claude Code bug.

The Issue

GitHub issue #76928 reports a failure mode worse than ordinary context loss. A user on the VSCode native extension (Windows) ran three rounds of AskUserQuestion to scope a data pipeline, then watched the assistant write a full multi-phase plan to a plan file. They interrupted right as the plan finished writing — to ask an unrelated UI bug question.

From that point on, the assistant’s active context no longer contained any trace of the earlier work. Asked what they’d worked on, it described only pre-planning repo orientation and asserted no planning session existed. It claimed there were zero AskUserQuestion calls in the session — trivially false. The user had to argue repeatedly and eventually get the assistant to parse its own raw session .jsonl on disk, where all three questions, answers, and the plan file were sitting intact the entire time. Nothing was actually lost. The live context simply never carried it past the interrupt.

The danger isn’t the data loss — it’s the confident denial. The agent sent the user on a wrong-track investigation of sibling projects instead of checking its own current transcript first.

Why Confident Denial Is Worse Than Silence

A normal error message (“context unavailable”) would prompt you to investigate. But the agent’s confident assertion that nothing happened actively misleads you. It is not guessing — it is generating a plausible-sounding narrative from truncated context, and it has no internal mechanism to flag that its memory is incomplete. This is fundamentally different from a cache miss or a null pointer. The agent is filling a gap with fiction and defending it as fact.

Are You Affected?

Check whether your live context matches your on-disk transcript after any interrupt:

# Find your session log
ls -t ~/.claude/projects/*/*.jsonl | head -1

# Grep the raw transcript for tool calls the agent claims never happened
grep -c "AskUserQuestion" ~/.claude/projects/*/$(ls -t ~/.claude/projects/*/*.jsonl | head -1 | xargs basename)

# List plan files written this session
ls -lt ~/.claude/plans/ | head

If the .jsonl shows tool calls or a plan your agent says do not exist, you’ve hit the bug.

Quick Self-Test

Run this diagnostic sequence after your next interrupt to catch the bug before it wastes your time:

Before interrupting: ask the agent “list every AskUserQuestion call in this session and its answer.”
Interrupt with Esc, ask an unrelated question, then resume.
Ask again: “list every AskUserQuestion call and its answer.”
If the second answer is shorter than the first — or denies calls the first listed — you have a confirmed context gap.

If you spot it early, you can re-state the decisions before the agent goes off-track.

The Fix

Immediate Steps

Do not trust amnesia. After any mid-turn interrupt, re-state the key decisions and ask the agent to confirm against its session file before moving on.
Keep plans on disk. Always have the agent write scoping decisions to a plan file — it survives the context gap even when live memory does not.
Recover via the transcript. If the agent denies prior work, point it at ~/.claude/projects/*/*.jsonl directly rather than accepting the denial.

Defensive Workflow Patterns

Pattern 1: Checkpoint before interrupt. Before hitting Esc, ask the agent to write a one-line summary of current state to a plan file:

Before I interrupt, write a one-line status summary to plans/session-status.md

After resuming, ask the agent to read that file back. This costs five seconds and prevents ten minutes of confused rework.

Pattern 2: The transcript audit. If you suspect context loss, do not argue with the agent. Instead:

# Dump the full session transcript
cat ~/.claude/projects/*/$(ls -t ~/.claude/projects/*/*.jsonl | head -1 | xargs basename) | \
  python3 -c "import sys,json; [print(json.loads(l).get('content','')[:200]) for l in sys.stdin if 'AskUserQuestion' in l or 'plan' in l.lower()]"

Then paste the relevant lines back into the conversation. The agent can process raw transcript content even if it lost the live context version.

Pattern 3: Two-session separation. If your workflow involves heavy planning followed by unrelated questions, run them in separate Claude sessions. Keep one session focused on the planning task; start a fresh session for unrelated questions. This sidesteps the interrupt-trigger entirely.

Recovering From Context Loss

If you are already in the “denial loop” — the agent insists work never happened and you are wasting cycles arguing — use this escape hatch:

# Find the session file
SESSION=$(ls -t ~/.claude/projects/*/*.jsonl | head -1)

# Extract the plan or decisions the agent wrote
grep -o '"plan_file":"[^"]*"' "$SESSION" | tail -1

# If a plan file exists, read it directly
cat ~/.claude/plans/$(grep -o '"plan_file":"[^"]*"' "$SESSION" | tail -1 | cut -d'"' -f4)

Feed the plan file contents back into the conversation. The agent will process the document and continue from where it left off — no more arguing required.

Why It Happened

The trigger is interrupting right as a tool call or plan write finishes. Context compaction (or post-interrupt context reconstruction) appears to diverge from the full session transcript, silently resetting the active window to an earlier point. Because nothing errors, the agent continues as if pre-interrupt work never occurred — and will defend that false state until forced to read its own log.

The likely mechanism: when an interrupt fires during or immediately after a tool call, the context reconstruction code snapshots the transcript at a point before the tool result was appended. The plan file write itself completed — that is a filesystem side-effect — but the in-memory context never incorporated the tool result that confirmed the write succeeded. The agent then has no representation of the planning work in its active window.

This is structurally similar to a race condition in event-sourced systems: the event (tool call result) was persisted, but the read model (active context) missed it due to a timing-dependent replay.

FAQ

Q1: Did I actually lose my work? No. The data is intact in ~/.claude/projects/*/*.jsonl and any plan file. Only the agent’s live, in-memory context lost it. Recover by referencing the transcript.

Q2: Is this a security vulnerability? Not a remote exploit, but it is a trust-safety problem: a confident, false denial can send you chasing phantom bugs or re-doing decided work. Treat agent “this never happened” claims as unverified after an interrupt.

Q3: Does this affect other agents? Any agent that compacts or reconstructs context after an interrupt can exhibit amnesia. Verify continuity by re-stating prior decisions before relying on them.

Q4: Is there a way to disable context compaction entirely? Not in the current Claude Code release. Context compaction is tied to the token window and cannot be toggled off. Your best defense is the checkpoint pattern: persist critical decisions to disk before any interrupt.

Q5: Does this happen with /compact manually, or only on interrupt? The reported trigger is interrupt-based, but manual /compact could theoretically produce the same gap if it snapshots before a tool result is fully incorporated. If you use /compact during active tool work, verify afterward by asking the agent to list recent tool calls.

Your AI tools should work for you, not your budget. Find savings at aiFiesta.

Beware: Claude Code Silently Drops Your Work After an Interrupt — Then Denies It Happened