›_ Claude Code Issues
Claude Code Issues / #73702

[Windows 2.1.199] VSCode extension spawns a leftover blank Chat channel after Reload/Restart (Root Cause: webview issues launch_claude before session-restore handshake resolves)

Open 💬 0 comments Opened Jul 3, 2026 by JUN-WEBLISS

[Windows] Claude Code VSCode extension spawns a leftover blank channel after PC restart with hot-exit workspace restore

Extension version: 2.1.198 and 2.1.199 (issue persists in both)
CLI version: 2.1.195
Platform: Windows 11 Pro 10.0.26200 (build 26200.8524), 32GB RAM
Node.js: v22.x (bundled with extension)
VS Code: stable

Update after filing: Confirmed the same behaviour in extension v2.1.199 immediately after auto-update. Two consecutive Reload Window tests within v2.1.199 both produced the two-channel pattern (spawn gap of 31s and 52s respectively). Root cause is not tied to a specific 2.1.19x point-release.

Summary

After a full PC restart, when VS Code restores workspaces via hot-exit, the Claude Code webview creates two separate launch_claude channels in parallel: (1) an empty New Chat channel with resume: undefined and (2) a channel that resumes the previously-open session with resume: <session-id>. Only channel (2) gets user attention; channel (1) is spawned but never killed by the extension, keeping a full MCP stack alive for ~49 minutes until it exits with code 4294967295.

The leftover claude.exe (channel 1) holds an idle claude.exe (~33MB WS) that independently spawns the full MCP stack (context7, firecrawl, canva mcp-remote, token-savior, 7x proxy-shim, npx wrapper double-hops = ~13 node.exe children per session). Doubling the entire stack via this ghost channel wastes roughly 1GB RAM for the whole session lifetime.

I could not find an existing issue that matches this specific trigger (PC restart + hot-exit workspace restore, 16-second gap between the two spawns). Nearby issues #32792/#14446/#22612/#42169/#29413 share the same root pattern ("new spawn without killing the old one") but with different triggers.

Steps to reproduce

  1. Have a VS Code workspace open with an active Claude Code session (any session-id).
  2. Restart the PC. VS Code restores the workspace via hot-exit.
  3. When VS Code reopens, the Claude Code webview activates.
  4. Observe (via Task Manager or wmic process where "name='claude.exe'" get ProcessId,CreationDate,CommandLine): two claude.exe are running instead of one.

Actual behaviour

From %APPDATA%\Code\logs\<TIMESTAMP>\window1\exthost\Anthropic.claude-code\Claude VSCode.log:

04:32:46.451 [info] Claude code extension is now active
04:32:46.451 [info] webview → launch_claude {channelId=blhej9nfre8}  ← 1st launch, no resume
04:33:09.744 [info] Spawning Claude with SDK query function ... resume: undefined
             → PID 2504, WS 32MB, CPU 7s cumulative, never grows

04:32:46.451 [info] list_sessions_request
04:33:16.917 [info] get_session_request {sessionId=d856783c-2d1f-42e8-99a0-63354b394563}
04:33:24.960 [info] webview → launch_claude {channelId=h7addwhup1}  ← 2nd launch, with resume
04:33:25.947 [info] Spawning Claude ... resume: d856783c-2d1f-42e8-99a0-63354b394563
             → PID 17640, WS 220MB, active session
             
… 49 minutes later …
05:22:57.129 [info] Closing Claude on channel: blhej9nfre8
             process exited with code 4294967295

Both PIDs share the same parent Code.exe extension host (PID 17228). Only one VS Code window is running (window1 is the only log directory). Every claude.exe independently spawns the full MCP stack, so ~13 node.exe children, 14 cmd.exe, 32 conhost.exe, ~1GB RAM are held twice for the whole session.

Expected behaviour

Either:

  • (A) The extension should reuse an already-running claude.exe from the initial webview activation when the "resume previous session" flow decides which channel to keep, killing the other.
  • (B) The initial launch_claude with resume: undefined should not spawn claude.exe until the webview has consulted the session store — i.e. the session-list/get-session handshake completes first, then a single launch_claude is issued with the resolved resume value.
  • (C) At minimum, the extension should track spawned claude.exe PIDs per channelId and terminate any channel that becomes orphaned (no user interaction, WS stable, spawned before the "current" resume channel).

Additional context

Race window timing: In this trace, the gap between the two spawns is 16 seconds (04:33:09 → 04:33:25). The gap is filled by the async list_sessions_request → list_remote_sessions → get_session_request handshake, which is what allows the second launch_claude to eventually carry the correct resume value. The first launch_claude fires unconditionally on webview activation, before this handshake has any chance to resolve.

Reproducibility observed across three separate reloads:

| # | Trigger | Extension | Blank channel spawn | Resume channel spawn | Gap |
|---|---|---|---|---|---|
| 1 | Full PC restart + hot-exit restore | 2.1.198 | 04:33:09.744 (PID 2504) | 04:33:25.947 (PID 17640) | 16s |
| 2 | Reload Window after extension auto-updated to 2.1.199 | 2.1.199 | 11:48:07 (PID 6500) | 11:48:38 (PID 7788) | 31s |
| 3 | Second Reload Window in 2.1.199 | 2.1.199 | 12:03:25 (PID 19012) | 12:04:17 (PID 19796) | 52s |

The gap varies (16s / 31s / 52s) but the pattern is deterministic: the first launch_claude from the webview always fires without a resume argument, and the extension spawns a claude.exe for it. The eventual "resume this session" channel arrives seconds to a minute later on a different channelId, and no cleanup of the earlier channel occurs.

Workaround in use: External watchdog (PowerShell) polling Get-CimInstance Win32_Process every 2 hours (scheduled task), killing claude.exe whose CommandLine has no --resume <session-id> argument when more than one is present. This is not a satisfying fix — the leftover process consumes MCP stack RAM for up to 2 hours before being reaped, and the pattern seems to be the same issue class already flagged in #62659 (Windows Job Object SILENT_BREAKAWAY_OK letting claude.exe children survive parent death).

Related issues (not duplicates but same class):

  • #32792 (Panel open increases claude.exe count) — reportedly fixed in v2.1.71, but this new trigger post-dates that fix.
  • #14446 (Extension Host restart orphans ~40 MCP processes).
  • #22612 (MCP server processes not cleaned up on session end).
  • #62659 (OPEN, Windows Bash tool grandchildren survive due to SILENT_BREAKAWAY_OK in Job Object).
  • #42169 (Multiple claude.exe accumulating, DWM restart).
  • #29413 (/clear + new chat leaves orphaned processes).

Environment details

  • extension: anthropic.claude-code v2.1.198 (from Marketplace, auto-installed at VS Code launch)
  • CLI: bundled inside extension at c:\Users\WEBLISS\.vscode\extensions\anthropic.claude-code-2.1.198-win32-x64\resources\native-binary\claude.exe
  • shell (Bash tool): G:\Program Files\Git\bin\bash.exe
  • MCP servers configured in .mcp.json: 12 (2 direct-npx + 7 via a local proxy-shim + 2 stdio native + 1 canva mcp-remote)
  • Extension logs attached above are from %APPDATA%\Code\logs\20260703T043054\window1\exthost\Anthropic.claude-code\Claude VSCode.log (available on request as raw file).

Happy to share the full log file or repro on request. Thanks for the great tool!

View original on GitHub ↗