[BUG] Claude Code VSCode extension webview "Not responding" on Windows 11 - terminal works, GUI does not

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39554
2. https://github.com/anthropics/claude-code/issues/39229
3. https://github.com/anthropics/claude-code/issues/39381

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I have the exact same problem, but only on Opus 4.6. Switching to Sonnet everything works fine.

I have the exact same problem, but only on Opus 4.6. Switching to Sonnet everything works fine.

Thanks for the tip, @Saturnix ! I actually tried switching to Sonnet as well, but unfortunately the issue persists on my end — the webview still shows "Not responding" regardless of the model selected. The ide_backend_stall_detected log keeps appearing with idleMs: 60000+ after every attempt, both with Opus 4.6 and Sonnet.

So it seems the root cause might be something more specific to certain Windows 11 configurations rather than just a model-level issue. Happy to provide any additional logs if that helps narrow it down.

+1 Experiencing the same issue on Windows 11 Pro (Build 26200).

Environment:

• Claude Code: v2.1.86 (latest as of 2026-03-27)
• VS Code extension
• Windows 11 Pro 10.0.26200

Symptoms:

• Extension shows "Not responding — try stopping" during tool calls (especially Agent subagents using WebSearch)
• Multiple sequential Bash calls sometimes cause the extension to hang indefinitely
• The terminal/CLI works fine — only the VS Code webview GUI is affected
• Have to manually interrupt and retry

Workaround:
Downgraded to v2.1.77 as suggested in #39682 — will report if this resolves the hangs.

This regression appears to have started around v2.1.78 based on other reports.

Thanks for sharing, @OQAY! Unfortunately, downgrading to v2.1.77 didn't fix the issue in my case, the CLI still works fine, but the VSCode extension Webview remains "Not responding".

The problem in my environment seems to be more specific than the regression introduced in v2.1.77. For now, the only reliable workaround I've found is using the web interface at claude.ai/code.

Hoping this helps Anthropic identify the different scenarios causing this behavior.

Environment: Windows 10 Enterprise 10.0.19045, VS Code extension

Started: ~2026-03-28

Symptom: Intermittently, after pressing Enter to submit a message, the extension appears to accept it but never sends it to the backend — no response is generated. The message is silently lost. Typing any follow-up message and pressing Enter again triggers a response (to both messages).

This is different from the "Not responding" spinner — there's no visual indication anything went wrong. It just looks like Claude is ignoring the message.

Exactly something similar happens to me on 3 machines with Windows 11 and VSCode 1.113, when I try to use Claude 3rd party models in vscode in built chat. Downgrade to 1.112 helps, but yeah it need to be somehow fixed. My response from chat was [reqest_interrupted_by_user], but I didin't interrupt anything.

Same issue, Claude Code stuck for a huge long time, a prompt will take over 1hour waiting.
asking AI for solution it claims that it is a known bug while running claude code on Windows due to python asyncio is not properlly supported.

It's been a month, has anyone found a fix yet? It always crashes after reading.

Cross-host data point — Linux + Cursor + sidebar mode, different surface, likely same root area

Filing alongside this to widen the scope. The hang isn't only on editor-tab restoration on macOS — the same Cursor-specific extension-activation problem also breaks session resume
in sidebar mode on Linux:

• Platform: Ubuntu 26.04, Cursor 3.3.27, Claude Code extension 2.1.138 (latest, released 2026-05-09).
• Surface: claudeCode.preferredLocation: "sidebar", claudeCode.useTerminal unset.
• Symptom: Clicking an existing conversation in the sidebar spawns ~/.cursor/extensions/anthropic.claude-code-2.1.138-linux-x64/resources/native-binary/claude …

--replay-user-messages. The child produces zero stderr between launch and interrupt. Webview spins forever; eventually Error: Interrupted during launch. A new conversation (no
resume) launches in ~7s.

• Native-binary-side evidence: every hung launch's argv contains "resume":"<sessionId>" and --replay-user-messages. Strongly suggests the failure is on the resume-handling path

inside the binary too, not just Cursor's webview-restore path.

• Orphan children: Cursor staff confirmed on the forum on 2026-04-27 that the extension host does not terminate spawned claude children on reload — they accumulate. Killing them

alone does NOT unstick the resume hang. Ref: https://forum.cursor.com/t/reload-window-does-not-terminate-extension-child-processes-claude-code-hangs/159070

• 2.1.138 (2026-05-09) does not fix it. Re-verified on 2026-05-11. The 2.1.138 changelog (Windows activation fix, /model picker, claude auth login improvements) doesn't touch this

path.

• Reliable workaround on Linux: claudeCode.useTerminal: true — launches claude in a Cursor terminal pane, bypassing the webview/IPC path entirely. Old conversations resume normally

there.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.