VS Code extension: uninterruptible processing loop causes irrecoverable data loss

Resolved 💬 5 comments Opened Apr 3, 2026 by j-p-c Closed May 13, 2026

Summary

When Claude Code enters an uninterruptible processing loop in the VS Code extension, user messages typed and submitted during the loop are silently lost — they are never persisted to the JSONL transcript. A regular Quit (Cmd+Q) is the only way to recover control. On relaunch, the conversation rolls back to before the loop began, and all user input during that window is irrecoverably gone.

Steps to reproduce

  1. During an active conversation in the VS Code extension, Claude begins a processing cycle (thinking/tool use)
  2. The processing enters a loop that never yields — no pause, no tool approval prompt, no opportunity to interrupt
  3. From the user's perspective, this looks identical to normal thinking — there is no indication anything is wrong until the duration becomes obviously excessive (10+ minutes)
  4. While Claude is spinning, the user can continue typing prompts and pressing Return — they queue up in the UI in the normal way, exactly as they would during normal processing
  5. The user performs a regular Quit (Cmd+Q) — not a force-quit. VS Code exits gracefully; the Claude Code extension does not block the exit but also does not persist the queued messages
  6. On relaunch (seconds later), the conversation has rolled back to before the loop began. All user messages typed during the freeze are gone

Expected behavior

  • User messages submitted during processing should be persisted to the JSONL transcript immediately, even if Claude hasn't responded yet
  • The Stop button and Escape key should interrupt the processing loop
  • At minimum, the UI should not accept and display user input that it will silently discard on exit

Actual behavior

  • 36 minutes of conversation were lost (14:03:52 → 14:40:09 UTC, verified from JSONL transcript)
  • The JSONL transcript contains zero user messages during the gap — only a last-prompt marker and 10 file-history-snapshot entries (no timestamps), suggesting the extension was doing housekeeping but not persisting conversation turns
  • Messages that appeared in the UI and were submitted by the user were never written to disk
  • The only record of the lost content exists because the user took screenshots and showed them to a new Claude session after restart
  • An average user without knowledge of JSONL transcripts would have no recovery path at all

Environment

  • VS Code extension (not CLI or Desktop App)
  • macOS
  • Claude Code with hooks (Alzheimer memory management — j-p-c/alzheimer)

Additional context

The user has a screen recording video of the full incident.

The freeze is indistinguishable from normal processing until the duration becomes obviously excessive. The user only realized after ~10 minutes that Claude was stuck. Because the queued messages appeared to be accepted normally by the UI, the silent data loss was completely unexpected.

Related: #11803 (Stop/Escape ignored in VS Code, closed as duplicate) covers the uninterruptible loop but not the data loss.

Note: The Alzheimer project (which was the subject of the lost conversation) has a planned "post-mortem" feature that would enable recovery from JSONL transcripts — but this requires knowledge that most users don't have, and shouldn't be necessary in the first place. Even worse, in this case post-mortem would not help either, because the lost messages were never written to the JSONL transcript at all.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗