VS Code extension hangs on tool dispatch — requests never reach the (healthy) daemon — Windows

Resolved 💬 4 comments Opened Jun 20, 2026 by Zahora19 Closed Jun 23, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug Report: VS Code extension hangs on tool dispatch — requests never reach the (healthy) daemon — Windows

Summary

The Claude Code VS Code extension hangs intermittently on tool/write actions (file read/write, Glob, MCP tool use). The spinner stays indefinitely and Esc does not abort. Crucially: with the background daemon running in the foreground (claude daemon run), the daemon shows NO incoming activity when the extension hangs — i.e. the request never reaches the daemon. The hang is in the extension / IDE-integration (named-pipe) layer, not the daemon, not MCP config, not user settings.

Environment

OS: Windows (win32-x64)
Claude Code: native install, v2.1.181 (auto-updated successfully 2026-06-18; latest available 2.1.183)
IDE: VS Code (Claude Code extension), freshly reinstalled
Auth: Claude Max subscription (OAuth, not API key)
Working directory: large Obsidian vault (~46,000 files incl. .git and many small files)

Key finding (most important)

claude daemon status → "not running", control.sock: unreachable (ENOENT \\.\pipe\cc-daemon-...-control), roster.json: absent, daemon.log: absent (note: on-demand daemon, so "not running" while idle is expected).
Started daemon in foreground: claude daemon run → starts cleanly:
[supervisor] ─── daemon start ─── version=2.1.181 pid=... origin=foreground
[supervisor] auth: scheduling proactive refresh ...
[supervisor] workers=0
With daemon running, triggered a tool action in the VS Code extension → extension HANGS, and the daemon foreground window shows NO new lines at all (no workers=1, no error).
→ The extension never reaches the daemon. The hang is upstream of the daemon, in the extension ↔ daemon (named pipe) connection.
Running Claude Code directly in the terminal (claude) is noticeably more stable than the extension — consistent with the hang being in the IDE-integration layer.

Symptoms

Intermittent freezes during a session on tool/write actions.
Reproducible pattern "first prompt hangs, second proceeds" (and recurs later).
Esc / Ctrl+C do not cancel; /compact does not help (not context overflow).
Occasional full crash/disconnect of the chat window (had to restart it).

Already ruled out / fixed (problem persists regardless)

Removed stale locked git worktrees (git worktree remove -f -f, prune).
Removed legacy plugins (privacy-legal, commercial-legal) + their dead MCP servers.
Removed dead marketplace claude-for-legal (was causing cache-miss poll every ~2s).
Removed Supabase plugin (cloned from GitHub each start); re-added Supabase as a direct MCP server.
Removed higgsfield MCP server (stuck on "needs authentication").
Rebuilt settings.json cleanly (valid JSON, no secrets).
claude mcp list: ALL servers Connected (github, n8n-mcp, playwright, supabase + claude.ai connectors). No failed/pending remain.
Reinstalled VS Code + Claude Code extension.
Updated to 2.1.181 (includes recent Windows hang/OOM fixes) — hang persists

Steps to reproduce

Open the vault folder in VS Code with Claude Code (Max/OAuth login).
(Optionally) run claude daemon run in a separate terminal to observe daemon activity.
Send a prompt that triggers a tool call (e.g. "check current status" → Glob/Read, or write to a note).
Observe: extension spinner hangs indefinitely; Esc does not cancel; daemon window shows no incoming activity.

Possibly related (changelog)

"Fixed claude -p being slow or appearing to hang on Windows while waiting for …"
"Fixed a crash (out-of-memory) when the CLI inherits a stale websocket/OAuth file-descriptor environment variable from a parent process"

Request

The daemon is healthy and idle; the extension never dispatches the request to it. Please advise on the extension ↔ daemon named-pipe connection on Windows. What additional diagnostics would help (extension output channel logs, named-pipe state)? Full claude --debug log and daemon foreground output available on request.

Current workaround

Using Claude Code via the terminal (claude) instead of the VS Code extension is more stable.

What Should Happen?

Bug Report: VS Code extension hangs on tool dispatch — requests never reach the (healthy) daemon — Windows

Summary

The Claude Code VS Code extension hangs intermittently on tool/write actions (file read/write, Glob, MCP tool use). The spinner stays indefinitely and Esc does not abort. Crucially: with the background daemon running in the foreground (claude daemon run), the daemon shows NO incoming activity when the extension hangs — i.e. the request never reaches the daemon. The hang is in the extension / IDE-integration (named-pipe) layer, not the daemon, not MCP config, not user settings.

Environment

OS: Windows (win32-x64)
Claude Code: native install, v2.1.181 (auto-updated successfully 2026-06-18; latest available 2.1.183)
IDE: VS Code (Claude Code extension), freshly reinstalled
Auth: Claude Max subscription (OAuth, not API key)
Working directory: large Obsidian vault (~46,000 files incl. .git and many small files)

Key finding (most important)

claude daemon status → "not running", control.sock: unreachable (ENOENT \\.\pipe\cc-daemon-...-control), roster.json: absent, daemon.log: absent (note: on-demand daemon, so "not running" while idle is expected).
Started daemon in foreground: claude daemon run → starts cleanly:
[supervisor] ─── daemon start ─── version=2.1.181 pid=... origin=foreground
[supervisor] auth: scheduling proactive refresh ...
[supervisor] workers=0
With daemon running, triggered a tool action in the VS Code extension → extension HANGS, and the daemon foreground window shows NO new lines at all (no workers=1, no error).
→ The extension never reaches the daemon. The hang is upstream of the daemon, in the extension ↔ daemon (named pipe) connection.
Running Claude Code directly in the terminal (claude) is noticeably more stable than the extension — consistent with the hang being in the IDE-integration layer.

Symptoms

Intermittent freezes during a session on tool/write actions.
Reproducible pattern "first prompt hangs, second proceeds" (and recurs later).
Esc / Ctrl+C do not cancel; /compact does not help (not context overflow).
Occasional full crash/disconnect of the chat window (had to restart it).

Already ruled out / fixed (problem persists regardless)

Removed stale locked git worktrees (git worktree remove -f -f, prune).
Removed legacy plugins (privacy-legal, commercial-legal) + their dead MCP servers.
Removed dead marketplace claude-for-legal (was causing cache-miss poll every ~2s).
Removed Supabase plugin (cloned from GitHub each start); re-added Supabase as a direct MCP server.
Removed higgsfield MCP server (stuck on "needs authentication").
Rebuilt settings.json cleanly (valid JSON, no secrets).
claude mcp list: ALL servers Connected (github, n8n-mcp, playwright, supabase + claude.ai connectors). No failed/pending remain.
Reinstalled VS Code + Claude Code extension.
Updated to 2.1.181 (includes recent Windows hang/OOM fixes) — hang persists.

Steps to reproduce

Open the vault folder in VS Code with Claude Code (Max/OAuth login).
(Optionally) run claude daemon run in a separate terminal to observe daemon activity.
Send a prompt that triggers a tool call (e.g. "check current status" → Glob/Read, or write to a note).
Observe: extension spinner hangs indefinitely; Esc does not cancel; daemon window shows no incoming activity.

Possibly related (changelog)

"Fixed claude -p being slow or appearing to hang on Windows while waiting for …"
"Fixed a crash (out-of-memory) when the CLI inherits a stale websocket/OAuth file-descriptor environment variable from a parent process"

Request

The daemon is healthy and idle; the extension never dispatches the request to it. Please advise on the extension ↔ daemon named-pipe connection on Windows. What additional diagnostics would help (extension output channel logs, named-pipe state)? Full claude --debug log and daemon foreground output available on request.

Current workaround

Using Claude Code via the terminal (claude) instead of the VS Code extension is more stable.

Error Messages/Logs

Steps to Reproduce

  1. On Windows, open a project folder in VS Code with the Claude Code extension (logged in via Claude Max / OAuth, not API key).
  2. (Optional, to observe the daemon) In a separate terminal, run: claude daemon run

It starts cleanly and prints: [supervisor] daemon start ... workers=0

  1. In the VS Code extension chat, send a prompt that triggers a tool call (e.g. "check the current status of this project" → triggers Glob/Read, or ask it to write to a file).
  2. Observe: the extension spinner hangs indefinitely. Esc / Ctrl+C do not cancel it. /compact does not help.
  3. Look at the "claude daemon run" terminal: NO new lines appear (no workers=1, no error) while the extension is hung — i.e. the request never reaches the daemon.
  4. Re-sending the same prompt sometimes proceeds (the "first prompt hangs, second runs" pattern), then recurs later.

Note: Running Claude Code directly in the terminal (claude) is stable at all times, which

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.181 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

With daemon running, triggered a tool action in the VS Code extension → extension HANGS, and the daemon foreground window shows NO new lines at all (no workers=1, no error).
→ The extension never reaches the daemon. The hang is upstream of the daemon, in the extension ↔ daemon (named pipe) connection.
Running Claude Code directly in the terminal (claude) is noticeably more stable than the extension — consistent with the hang being in the IDE-integration layer.

View original on GitHub ↗

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