VSCode: Config probe subprocess always times out (60s) on first tab

Bug description

When opening a new Claude Code tab in VSCode, the extension spawns a config probe subprocess (spawnConfigProbe() — "Loading config cache by launching Claude (no channel)...") that systematically times out after 60s with:

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

The actual session subprocess boots fine (<1s) and works normally. But the error banner is shown to the user, who thinks the session failed. They have to re-submit their message to get a response.

Environment

• Claude Code extension: 2.1.143 (darwin-arm64)
• VSCode: latest stable
• OS: macOS 15.4 (Darwin 25.3.0), Apple Silicon
• Auth: AWS Bedrock (CLAUDE_CODE_USE_BEDROCK=1)
• Model: global.anthropic.claude-opus-4-6-v1
• Working directory: OneDrive-synced folder (via macOS FileProvider)

Root cause analysis

From the extension logs (Anthropic.claude-code/Claude VSCode.log), here's what happens every time a tab is opened:

Timeline (real example)

| Time | Event |
|------|-------|
| 21:31:00.517 | Tab opened, launch_claude on channel rte2nvylv5g |
| 21:31:00.950 | Both processes start init (config probe + real session) |
| 21:31:01.057 | MCP servers init, hooks start |
| 21:31:01.109 | SessionStart hooks complete (AWS creds ✓, startup script ✓) |
| 21:31:01.339 | Atlassian MCP connected (283ms) |
| 21:31:01.698 | Skills/commands loaded |
| 21:31:02.015 | All hooks done — both processes are ready in ~2s |
| 21:31:08.853 | User sends message on channel rte2nvylv5g |
| 21:32:00.704 | Config probe times out (exactly 60s after launch) |
| 21:32:27 | Second attempt succeeds, session works |

Key finding

The config probe subprocess completes its full initialization in <1s (visible in logs: startup, hooks, MCP all complete by 21:31:02). But the extension never receives/acknowledges the initializationResult() from the probe, so it waits the full 60s timeout.

The real session channel works fine. After the probe timeout, the session process's getSettings() call succeeds and caches the config. Subsequent tabs work immediately.

Code path (from minified extension.js)

// spawnConfigProbe spawns a full Claude process just to call getSettings()
async spawnConfigProbe() {
    this.logger.log("Loading config cache by launching Claude (no channel)...");
    // ... spawns full Claude binary with all hooks, MCP, skills ...
    await q2(L.initializationResult(), K, 
        `Subprocess initialization did not complete within ${K}ms — check authentication and network connectivity`);
    let N = await V.getSettings();
    this.cachedClaudeSettings = N;
}

The probe and the real session subprocess race for the same resources. The probe always loses and times out.

Reproduction

1. Open VSCode with Claude Code extension on any project
2. Open a new Claude Code tab (first tab after VSCode launch)
3. Type any message and send
4. → Red error banner appears: "Subprocess initialization did not complete within 60000ms"
5. Re-submit the same message → works immediately
6. Open another tab → works immediately (config now cached)

Consistent pattern from logs

Every single tab opening produces this pattern:

"Hook SessionStart:startup success" (probe is READY)
  ... 58 seconds of silence ...
"Error spawning Claude: Subprocess initialization did not complete within 60000ms"
"Failed to load config cache: Subprocess initialization did not complete within 60000ms"

The probe IS ready (hooks succeed), but initializationResult() never resolves from the extension's perspective.

Impact

• Users see a scary red error on every first tab
• Users think the session failed and re-submit their question
• Wastes 60s on every VSCode launch

Suggested fixes

1. Don't block on the config probe — load config lazily from the first real session instead
2. Increase or remove the probe timeout — the probe finishes in <1s, it's the IPC that's slow
3. Don't show the error banner for config probe failures — it's not a session failure
4. Reuse the first real session's config instead of spawning a separate probe process