[BUG] Claude Code 60s Timeout

Confirming this on Windows 10 too, via the VS Code Claude Code extension. Same exact error text, same intermittent pattern — sometimes launches clean, sometimes doesn't, no consistent trigger. Reproduced across multiple weeks and CLI versions (2.1.195 through 2.1.220), so this isn't a one-off or tied to a specific release.

My debug logs (View output logs in the extension) show the same underlying pattern as the now-closed #62327:

[Bootstrap] Fetch failed: ECONNABORTED
[ERROR] [Bootstrap] fetchBootstrapData failed: AxiosError: timeout of 5000ms exceeded
[ERROR] Failed to fetch MCP registry: timeout of 5000ms exceeded

Before landing on this as the likely root cause, I ruled out several other real-but-separate issues that were contributing noise on my end: stale .claude\ide\*.lock files from crashed sessions, a missing CLAUDE_CODE_GIT_BASH_PATH, a project-scoped playwright MCP server with its own 30s connection timeout, and orphaned chrome.exe processes from an interrupted Playwright install. Fixing each of those reduced frequency but never eliminated the failure. Also tried the full env var workaround block from #62327 (BUN_CONFIG_DISABLE_HTTP2, NODE_OPTIONS=--dns-result-order=ipv4first, etc.) — no measurable effect, consistent with what that issue's original reporter found.

Your finding about spawnConfigProbe() completing but its result never reaching the extension's initializationResult() acknowledgment lines up with what I'm seeing — the underlying config/session data often does complete successfully in the logs, it's specifically the acknowledgment back to the extension UI that seems to be the failure point. Happy to share full logs if it helps narrow this down further.

Thanks for the detailed report. We tried to reproduce this on the released 2.1.233 build, but the failure mode is Windows-only (native Windows + the VS Code/Cursor extension) and we can't currently exercise that setup on the machine we triaged from, so we can't confirm or rule it out ourselves. Reviewing the intended behavior: the extension is expected to start a session and apply a model change within a few seconds; a 60-second startup timeout is never expected, so we're treating this as a bug rather than a configuration problem, and we agree the "check authentication and network connectivity" wording is misleading for this case.

We haven't found a fix that landed after 2.1.220, so this is still open as far as we know. To narrow it down, could you (or anyone else hitting it) share:

• The full "Claude Code" output-channel log from one failing launch (from extension activation through the 60s error), with anything sensitive redacted
• Whether it happens on the current extension version (2.1.233), and roughly how often (every launch vs. intermittent)
• Whether it still happens with all project/user MCP servers temporarily removed
• The output of claude doctor from the same machine

If several of you can post logs from failing runs we can compare them for the common point where the handshake stalls.

🤖 Generated with Claude Code

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

Thanks for the detailed triage questions @bcherny. I've now isolated this to a concrete, reproducible mechanism rather than a random timeout, and I have evidence for each of your asks.

Answers to your four questions:

1. Version / frequency: 2.1.231 CLI + 2.1.220 extension on Windows 11 (Cursor). Intermittent, but with a pattern: works after a reboot, then a new session fails later in the day, and killing/reopening Cursor doesn't fix it. That "fails later" signature is the tell — it tracks a debounced background job crossing its due-window, not auth or network.

1. MCP removed: N/A. The failing config has zero MCP servers (mcpServers: {} in both ~/.claude.json and project settings). It reproduces with a clean default config, so MCP is ruled out.

1. claude doctor: CLI, terminal, and desktop all work; only the extension's spawned subprocess hangs. The extension log shows OAuth tokens found in secure storage immediately before the 60s timeout, and the CLI answers claude -p fine.

1. Log shape (the important part): SessionStart hooks finish ~1s after spawn, then there's ~59s of silence, then the kill at exactly +60.0s. The subprocess is alive and healthy after the kill — the log continues with [skills] idle — switching poll interval to 30000ms after the watchdog fired.

The mechanism I found (this is the actionable part):

The 60s gap between "hooks finished" and "init-complete ack" is real work the subprocess is still doing — SessionStart hooks, not an idle stall. On a hook-heavy repo the hook chain itself can consume the entire budget:

• .claude/settings.json ran 8 SessionStart hooks totalling ~58s worst-case (measured per-hook with timestamps).
• The dominant hook (a model router validation) launches a maintenance job with ( cmd ) &. The backgrounded subshell inherits the hook's stdout pipe, so the hook harness reads stdout until EOF and blocks until that detached job finishes — including a ~15s text classification and word representations model train and a live API canary. When the maintenance debounce stamp was stale, the hook alone took 30-60s. This is the classic "detached grandchild inherits the stdio pipe" hang #84864 describes, but on the SessionStart path, not MCP.
• A second hook (a memory reader) spawned ~64 per-file git log processes ≈ 10s.
• On Windows, antivirus real-time scanning multiplied every process spawn ~10x (measured printf at 632ms vs ~50ms with exclusions), turning dozens of hook spawns into extra seconds.

Repro you can run anywhere:

# time a single SessionStart hook under captured stdout (the hook's real condition)
time bash .claude/scripts/<sessionstart-hook>.sh

Before the fix: ~30-60s when maintenance is due. After fixing the backgrounded subshell to close its own fds (( cmd ) </dev/null >/dev/null 2>&1 &), the same hook returns in ~1.5s while the train runs detached.

The fix that resolved it (repo-side, no extension change needed):

• ( bash ... ) </dev/null >/dev/null 2>&1 & — the trailing redirections belong to the subshell, not the inner command; without them the subshell holds the caller's stdout pipe open until it exits.
• Batched the per-file git log calls in the memory hook into one pass (~10s → ~0.3s).
• SessionStart chain went from ~58s to ~15s; after also excluding the repo + Git from the AV scan, ~10-12s.

What would help you fix the extension side: the watchdog kills at 60s even when the subprocess is healthy and still running hooks. A SessionStart hook chain that legitimately exceeds the budget is treated identically to a hung probe. Two cheap wins: (a) start the 60s clock after SessionStart hooks complete (or include hook time in the budget explicitly), and (b) when the timeout fires, report what the subprocess was last doing (its final log line before the kill) instead of blaming auth/network — every reporter here wasted days chasing the wrong subsystem.

Happy to share the full redacted output-channel log and the hook-timing harness if it helps correlate against your internal repro.