[BUG] VS Code extension: Subprocess initialization always times out (60s) — TCP/TLS/proxy all confirmed working externally

Status Open
Reported on v2.1.112
Maintainer reply None cached
Activity 4 comments · opened Jul 15, 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?

The VS Code extension's subprocess initialization always times out after
60 seconds, even though the underlying network, TLS, and certificate trust
chain are all confirmed working. The hang reproduces identically when running
claude -p ping manually in VS Code's integrated terminal — it is not
specific to the extension's spawn mechanism, but to something in the
process environment VS Code provides to its child processes.

What Should Happen?

The VS Code extension's subprocess initialization always times out after
60 seconds, even though the underlying network, TLS, and certificate trust
chain are all confirmed working. The hang reproduces identically when running
claude -p ping manually in VS Code's integrated terminal — it is not
specific to the extension's spawn mechanism, but to something in the
process environment VS Code provides to its child processes.

Error Messages/Logs

Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

Steps to Reproduce

  1. Open VS Code on Windows 11 with Claude Code extension installed (2.1.112

or 2.1.209 both reproduce)

  1. Open integrated terminal (Terminal > New Terminal)
  2. Run: claude -p ping
  3. Observe: hangs indefinitely, no response, no error
  4. Separately: open Claude Code panel in VS Code, send any message
  5. Observe: after 60s, "Subprocess initialization did not complete within

60000ms — check authentication and network connectivity"

  1. Open a terminal OUTSIDE VS Code (e.g. standalone PowerShell window)
  2. Run: claude -p ping
  3. Observe: responds immediately

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.209 and 2.1.112 both fail

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

4 Comments

tpozzy · 1 month ago

Process Monitor trace (Sysinternals ProcMon) during the hang

claude.exe enters an infinite polling loop, repeating identically every
~1 second for the full 60+ second duration with NO network activity
whatsoever (no DNS, no socket, no TLS):

  1. CreateFile: C:\Users\<user>\.claude.json
  2. CreateFile: <project>\.git\HEAD
  3. CreateFile: <project>\.git\config
  4. CreateFile: <project>\.git\refs\heads\main

(repeat from step 1)

This strongly suggests the extension is stuck in a file-watch/git-status
polling loop and never proceeds to actually attempt the network
initialization that the timeout error message references. The error
message "check authentication and network connectivity" is misleading —
no network I/O is ever attempted in this trace.[

Logfile.CSV

](url)

tpozzy · 1 month ago

Follow-up test: disconnected the project from git entirely (renamed .git
folder) to test whether the file-polling loop identified in the ProcMon
trace was git-related.

Result: failure mode changed. Instead of the 60s "Subprocess initialization
did not complete" timeout, got a faster failure (~8s) with a different error:
"Query closed before response received" / "Failed to load config cache:
Error: Query closed before response received"

This suggests git state was involved in the original hang, but wasn't the
sole cause — removing it exposed a second, faster-failing issue rather than
resolving cleanly.

tpozzy · 1 month ago

ROOT CAUSE IDENTIFIED (after full clean-slate reset: fresh Windows VS Code
install, fresh Claude Code 2.1.210, fresh ~/.claude.json, empty test project):

During login, ~/.claude.json is written 4+ times in rapid succession
(within ~400ms) as separate internal processes persist auth tokens, MCP
server config, and settings concurrently. Immediately after, an auth-status
read of the same file fails with "SyntaxError: Unexpected end of JSON
input" — consistent with the reader catching the file mid-write/mid-rename
during the write-temp-then-atomic-rename pattern used elsewhere in the logs.

This produces: "claude auth status parse failed" -> "Failed to retrieve
auth status after login" -> login appears to fail even though the OAuth
flow itself completed successfully (MCP servers fetched, tokens presumably
written).

This exact "auth status parse failed" error appears in every prior log
across ~15 reproduction attempts spanning different VS Code versions,
Claude Code versions, network configs, and antivirus states — suggesting
this race condition, not any client-side environment factor, is the actual
root cause of the broader initialization failures reported in this issue.

tpozzy · 1 month ago

FOUND WORKING VERSION: Claude Code 2.1.78 (approx. 4 months old) works
correctly in the same environment where 2.1.112 through 2.1.210 all fail
with the reported symptoms.

This narrows the regression window to somewhere between 2.1.78 and 2.1.112.
If a changelog or diff is available for that range, the "auth status parse
failed" / concurrent .claude.json writes issue is likely traceable to a
specific change in that window.