[BUG] VS Code extension: Subprocess initialization always times out (60s) — TCP/TLS/proxy all confirmed working externally
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 runningclaude -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 runningclaude -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
- Open VS Code on Windows 11 with Claude Code extension installed (2.1.112
or 2.1.209 both reproduce)
- Open integrated terminal (Terminal > New Terminal)
- Run: claude -p ping
- Observe: hangs indefinitely, no response, no error
- Separately: open Claude Code panel in VS Code, send any message
- Observe: after 60s, "Subprocess initialization did not complete within
60000ms — check authentication and network connectivity"
- Open a terminal OUTSIDE VS Code (e.g. standalone PowerShell window)
- Run: claude -p ping
- 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_
4 Comments
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):
(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)
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.
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.
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.