KBCodeKB
Unverified

Fix VS Code Claude Code "Not Responding" Session Hang (v2.1.84) — No Stop/Recover Button for Stuck Tasks

When Claude Code running in VS Code (v2.1.84 and earlier) gets stuck during a multi-step task, the UI displays "Not responding - try stopping" but provides NO actionable way to stop, cancel, or recover. The session becomes a dead end — users must force-quit VS Code and lose all progress, including completed tasks upstream of the stall. This occurs when a task involves an external operation (e.g., `gh repo create`, network calls) that hangs beyond the backend heartbeat timeout of 60 seconds. The spinner turns red but there is no stop button, cancel button, retry option, or task-skip mechanism. Anthropic staff member qing-ant confirmed the timeout was too aggressive and deployed a fix in the March 27, 2026 release (v2.1.86). The affected version v2.1.84 was published March 25, 2026 and the fix version v2.1.86 was published March 27, 2026 — same day the issue was closed. Latest Claude Code as of June 13, 2026 is v2.1.177.

Symptoms

  • VS Code Claude Code panel shows red asterisk with text: "* Not responding · try stopping"
  • No Stop or Cancel button visible next to the "Not responding" message — only informational text
  • Session becomes completely unresponsive — cannot skip the stuck task or continue with remaining tasks
  • Completed tasks (e.g., 7 of 10) are lost when force-quitting, with no way to salvage finished work
  • No error message, stack trace, or timeout indication beyond the red text in the status bar
  • Occurs during multi-step tasks when external operations (gh repo create, network calls) hang beyond 60 seconds

Error signatures

* Not responding · try stopping
Red spinner/asterisk indicator in Claude Code VS Code panel
Session unresponsive for >60 seconds without recovery UI

Possible causes

  • The VS Code extension backend heartbeat timeout was set too aggressively at 60 seconds, triggering the "Not responding" state before slower external operations like `gh repo create` or network-dependent tool calls could complete their work
  • When the backend process (Claude Code CLI) is blocked waiting for an external command to return, it stops sending heartbeat signals to the VS Code extension host, which then declares it unresponsive after the timeout threshold is exceeded
  • The UI treats "Not responding" as informational text rather than an error state with recovery options — unlike VS Code's own extension host which offers "Restart Extension Host" as a clickable action when extensions hang
  • The task execution model runs synchronously within a single Claude Code session — when one task stalls, all subsequent tasks are blocked because there is no per-task timeout or skip mechanism

Solutions

Preventative: Batch Large Tasks With Checkpoints

risk: lowgithubpublished

Structure multi-step tasks into smaller, independently-runnable chunks so that if one operation hangs, you only lose the progress of that specific chunk rather than all 10+ tasks. Commit after each batch as a git checkpoint.

  1. Instead of one large prompt with 10 steps, break into 2-3 batches (e.g., setup, features A-C, features D-F)
  2. After each batch: `git add -A && git commit -m "batch N: <description>"`
  3. Start each new batch in a fresh Claude Code session (Cmd+Shift+P → "Claude Code: Open")
  4. For known-slow external operations, run them as standalone `claude -p` one-shots first

Commands

claude -p "batch 1: set up project structure and configure dependencies"
git add -A && git commit -m 'batch 1: project setup'
claude -p "batch 2: implement feature set A"

Risks

  • Breaks the continuity of complex multi-step sessions — requires manual checkpoints between batches
  • May increase token usage (each new session re-sends project context) — offset by avoiding lost-progress rework

Verification

  • Step 1: After batch 1, run `git log --oneline -1` → expect: commit message "batch 1: project setup" confirming checkpoint saved
  • Step 2: Run `git diff --stat HEAD~1` → expect: lists files changed in batch 1 with insertion/deletion counts
  • Step 3: Start batch 2 in a new session → expect: Claude Code reads the git history and project files from the committed state, not from the interrupted session
✓ 0 verified✕ 0 failed

Immediate Workaround: Kill Backend Process Without Closing VS Code

risk: lowgithubpublished

When the session is stuck with "Not responding", kill only the Claude Code backend CLI process via VS Code's terminal instead of force-quitting VS Code entirely. This preserves your VS Code workspace state, open files, and unsaved editor changes. Only the Claude Code session is lost.

  1. Open VS Code's integrated terminal (Ctrl+` or Cmd+`)
  2. Find the Claude Code backend PID: `pgrep -f '@anthropic-ai/claude-code'` — expect a numeric PID
  3. Kill: `kill -9 $(pgrep -f '@anthropic-ai/claude-code')`
  4. Verify cleanup: `ps aux | grep '[c]laude-code'` → expect: no output (all dead)
  5. Re-open Claude Code in VS Code (Cmd+Shift+P → "Claude Code: Open") and restart your task

Commands

pgrep -f '@anthropic-ai/claude-code'
kill -9 $(pgrep -f '@anthropic-ai/claude-code')
ps aux | grep '[c]laude-code'

Risks

  • All in-progress Claude Code session data is lost — must restart the task from the beginning
  • If Claude Code was mid-file-write, files may be left in an inconsistent state; always run `git diff` after recovery
  • Force-killing may leave orphaned child processes; confirm all are gone with `ps aux | grep claude`

Verification

  • Step 1: Run `pgrep -f '@anthropic-ai/claude-code'` → expect: a numeric PID on stdout (e.g., "12345"), exit code 0. If exit code 1 (no match), the process already died — proceed to Step 3.
  • Step 2: Run `kill -9 $(pgrep -f '@anthropic-ai/claude-code') 2>&1; echo exit=$?` → expect: "exit=0" confirming successful kill. If "exit=1" with "kill: No such process", the process already exited.
  • Step 3: Run `ps aux | grep '[c]laude-code'` → expect: NO output (empty stdout). If output appears, repeat Step 2 for remaining PIDs.
  • Step 4: Run `git diff --stat` in your project directory → expect: either no output (clean working tree) or only expected file changes. Check for any corrupted or partially-written files from the interrupted session.
✓ 0 verified✕ 0 failed

Update Claude Code to v2.1.86+ (Permanent Fix — Staff-Confirmed)

risk: lowofficialpublished

Anthropic staff member qing-ant confirmed the fix: "Fixing this in tomorrow's release! The timeout we set there was a bit too aggressive." The fix shipped in v2.1.86 (published March 27, 2026) which adjusts the backend heartbeat timeout. The spinner still turns red after 60 seconds as a visual indicator, but the backend no longer times out prematurely for legitimate long-running external operations. Update to v2.1.86 or later.

  1. Check current version: `claude --version` — if ≤ v2.1.85, the bug is present
  2. Update: `npm update -g @anthropic-ai/claude-code`
  3. Verify fix version exists on npm: `npm view @anthropic-ai/claude-code@2.1.86 version` → should return "2.1.86" (status 0)
  4. Compare: `npm view @anthropic-ai/claude-code@2.1.84 version` → should return "2.1.84" confirming the affected version was real
  5. Restart VS Code fully (Cmd+Q, reopen) to reload the extension with the updated CLI
  6. Verify: `claude --version` → expect ≥ 2.1.86

Commands

claude --version
npm update -g @anthropic-ai/claude-code
npm view @anthropic-ai/claude-code@2.1.86 version
npm view @anthropic-ai/claude-code@2.1.84 version
npm view @anthropic-ai/claude-code version

Risks

  • External operations that genuinely exceed even the adjusted timeout (e.g., cloning very large repos, extremely slow third-party APIs) may still trigger the red spinner indicator, though the session should recover once the operation completes
  • Update may introduce other regressions; test on a non-critical project first

Verification

  • Step 1: Run `claude --version` → expect: version string containing ≥ 2.1.86, e.g., "2.1.177 (Claude Code)" as of June 2026. Exit code MUST be 0.
  • Step 2: Run `npm view @anthropic-ai/claude-code@2.1.86 version 2>&1` → expect stdout: "2.1.86", exit code 0. If exit code is non-zero (e.g., 1 with "npm error code E404"), the version does not exist on the registry — abort.
  • Step 3: Run `npm view @anthropic-ai/claude-code@2.1.84 version 2>&1` → expect stdout: "2.1.84", exit code 0. This confirms the affected version exists on npm and you can compare timestamps.
  • Step 4: Restart VS Code (Cmd+Q, wait 3 seconds, reopen). Start Claude Code and run a multi-step task with an external operation. Example: `mkdir -p /tmp/test-cc && cd /tmp/test-cc && claude -p "create a new file called hello.py with print('hello world') and then run git init, git add ., and git commit -m initial"` → expect: all steps complete, no "Not responding" dead-end.
✓ 0 verified✕ 0 failed

Agent JSON

Canonical machine-readable representation of this issue:

{
  "issue_id": "36aa4169-1f95-445a-981c-278e4aea0df2",
  "slug": "fix-vs-code-claude-code-not-responding-session-hang-v2-1-84-no-stop-recover-button-for-stuck-tasks-nx3v4w",
  "verification_status": "unverified",
  "canonical_json": "https://codekb.dev/v1/issues/fix-vs-code-claude-code-not-responding-session-hang-v2-1-84-no-stop-recover-button-for-stuck-tasks-nx3v4w"
}
← Back to all issuesPowered by CodeKB