[BUG] VS Code: "Not responding - try stopping" offers no way to actually stop or recover

[ojhurst]

What's Wrong?

When Claude Code gets stuck during a task, the UI shows "Not responding - try stopping" — but there is no actionable way to stop. No stop button, no cancel, no retry. The only option is to kill the session entirely and lose all progress.

This is the worst UX failure in Claude Code right now. "Try stopping" is not a solution — it's the app throwing its hands up. The user is left staring at a dead session with no recourse.

What Should Happen?

When a task stalls, the extension should fail gracefully:

1. Show a visible Stop/Cancel button next to the "Not responding" message — not just text that says "try stopping"
2. Allow recovery without killing the session — skip the stuck task and continue, or retry it
3. Timeout and fail the individual task after a reasonable period (30-60 seconds) rather than hanging indefinitely
4. Preserve completed work — if 7 of 10 tasks completed successfully, those results should survive even if task 8 fails

Right now "Not responding" is a dead end. The user has to force-quit and restart from scratch.

Steps to Reproduce

1. Open Claude Code in VS Code (extension v2.1.84)
2. Start a multi-step task that uses the todo/task panel (e.g., building a new repo with ~10 steps)
3. Let Claude work through several tasks (7 of 10 completed in this case)
4. When a task involves an external operation (like gh repo create or a network call), it stalls
5. The task shows a red asterisk. The bottom of the panel shows: * Not responding · try stopping
6. There is no stop button, no cancel, no skip. The session is dead.

Error Messages/Logs

No error message — just the red text:

* Not responding · try stopping

No stack trace, no timeout error, no indication of what went wrong.

Environment

Detail	Value
Claude Code Version	2.1.84
Claude Model	claude-opus-4-6 (1M context)
Platform	Max plan
Operating System	macOS 26.3.1 (Darwin 25.3.0)
Terminal/Shell	VS Code integrated terminal (zsh)
Machine	MacBook Pro, Apple M2 Pro, 16 GB
VS Code	1.112.0
Claude Code Extension	anthropic.claude-code@2.1.84

Is this a regression?

Don't know — but this happens frequently enough to be the single most frustrating part of using Claude Code daily.

Additional Information

The core problem is that "Not responding" is treated as informational text rather than an error state with recovery options. Compare to how VS Code itself handles unresponsive extensions — it offers "Restart Extension Host" as a clickable action. Claude Code should offer equivalent escape hatches.

Related issues:

• [BUG] VS Code extension host 'Not responding' — ping/pong heartbeat timeout during tool execution #39229 — extension host heartbeat timeout (same symptom, different root cause)
• [BUG] Claude Code VS Code extension "Not responding" on WSL2 - WebSocket timeout loop #39183 — "Not responding" on WSL2
• [DOCS] VS Code extension docs missing "Not responding" red spinner indicator after 60-second backend timeout #38580 — docs missing the red spinner indicator

This is not an edge case. It happens regularly during multi-step tasks and forces a full session restart every time.

[RR-RC-GBR]

Im experiencing this now...

[Adrikinart]

i'm also experiencing that but when waiting enough time, it works for me

[mhartman88]

I have been experiencing this issue too. The first couple of times I had this happen to me, I was able to click the stop button (what was the submit button), and then I asked Claude to continue what I was previously working on. Usually, it would say that the work was already completed. In my experience, this issue seems to occur when I'm in Planning mode. I cannot say it only happens in Planning mode.

After experiencing this a third or fourth time, I searched to see if this bug had been reported as an issue. In the time it took me to find this Issue (maybe 2-3 minutes at most), I went back to my VS Code window and saw that the "Not responding - try stopping" message was gone and I had another permission prompt waiting for me.

This is definitely an inconvenience. If I continue to experience this issue, I'll start timing how long it takes for it to recover.

[vitorschiavo-verifymy]

I have been experiencing this issue too

[thethiny]

Damn it started with me now as well

[Valentyn-Kubrak]

the same issue

[Matheusrlr]

The same issue here, and happens in all modes

[balajeeraman]

Same issue, and I've to kill it

[AfonsoPCP]

Same issue, it takes a large amout of time, but it works

[vmaschio]

I'm going through the same thing. Between today and yesterday I experienced this at least 5 times, and in one instance it consumed almost 10% of my session usage.