Interrupting mid-turn silently drops already-completed work from active context, with no warning and confident denial on query

Environment: Claude Code VSCode native extension, Windows, single project/session.

What happened (reconstructed from the raw session .jsonl, timestamps included):

1. 13:38–13:45 — three rounds of AskUserQuestion ran in the session, covering real scoping decisions for a data pipeline (disk/bandwidth budget, which real dedup test cases to include, WSL2 setup feasibility). User answered all three, including two free-text answers that weren't from the provided options.
2. 13:47–13:48 — assistant wrote a full multi-phase execution plan to a plan file, incorporating all those answers plus real findings from inspecting the user's actual data.
3. 13:48:09 — user sent an interrupt ([Request interrupted by user]) right as the plan file finished writing, to ask an unrelated question (a UI display bug).
4. 13:50 onward — from this point on, the assistant's active context no longer contained any trace of steps 1–3. Asked later "what did we work on," the assistant answered from a state that began after the interrupt, describing only pre-planning repo orientation, and stated with full confidence that no such planning session existed.
5. When the user insisted the work happened, the assistant searched the wrong places (a sibling project directory, a different session file) and repeatedly told the user no such content existed anywhere — including asserting there were zero AskUserQuestion calls in the session, which was false.
6. Only when the user pushed back a second time did the assistant parse the raw session .jsonl on disk directly (not relying on its own active context) and discover: 3 AskUserQuestion tool calls, full question/answer content, and the plan file — all fully intact on disk the entire time. Nothing was actually lost; the assistant's active context simply never carried it after the interrupt point.

Why this matters / severity:

This is worse than ordinary context loss, because the failure mode is confident denial, not an error or a visible gap. The assistant:

• Asserted specific false facts ("zero AskUserQuestion calls in this session") that were trivially disprovable by reading its own session log.
• Sent the user on a wrong-track investigation (checking sibling projects, other sessions) instead of first checking whether its own current session's raw transcript matched its active context.
• Required the user to argue repeatedly and eventually get the assistant to do log forensics on itself, to recover work that had already been fully decided and was sitting untouched in two files the whole time (~/.claude/projects/<proj>/<session>.jsonl and a plan file under ~/.claude/plans/).

For an agentic tool where users are expected to trust multi-turn planning (especially AskUserQuestion-based scoping decisions), silently losing continuity across an interrupt — with no indication to the user that this happened — is a serious trust problem, independent of whatever technical cause (compaction, interrupt handling, context window reconstruction after an interrupt) produced it.

Ask:

1. When an interrupt causes the active context to diverge from the full session transcript, surface that to the user explicitly (e.g., "context was reset after that interrupt, resuming from an earlier point") rather than silently continuing as if nothing preceded it.
2. Before an assistant asserts "this didn't happen" / "I have no record of X" in response to a user's claim about earlier-session work, it should be prompted/able to check the raw session transcript file for the current session first, not just its live context — the data test used here (grepping the session .jsonl for tool_use names and content) is what eventually found the truth, but only after several failed attempts pointed elsewhere.
3. If this is a known consequence of context compaction interacting with mid-turn interrupts specifically, that interaction should be called out in compaction docs, since "interrupt right as a tool call/plan finishes" seems to be the trigger here.

Happy to share the exact session file (redacted) if useful for repro.