[BUG] Subprocess 60000ms timeout on startup when permission allow rules reference temporarily unmounted drives (Windows)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code VSCode extension fails with Subprocess initialization did not complete within 60000ms — check authentication and network connectivity after a reboot, when ~/.claude/settings.json contains permission allow rules and/or additionalDirectories entries pointing to drive-letter paths that haven't finished mounting yet.

The drives were reachable when Claude Code added the permissions automatically during a past session. After reboot they mount asynchronously — Claude Code hangs waiting on them during startup. The critical detail: the user has no reason to connect a reboot to Claude Code's startup failure, because these paths are written silently by Claude Code itself — the user never touches settings.json. Retrying a few minutes later (once drives are up) works fine.

What Should Happen?

Claude Code should skip or timeout individual unresolvable paths gracefully rather than blocking the entire subprocess initialization.

Error Messages/Logs

[error] Error spawning Claude: Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

Steps to Reproduce

1. Work in a session that uses a path on a secondary drive (e.g. G:\projects\work) — Claude Code automatically adds Read(//g/projects/work/**) to ~/.claude/settings.json
2. Reboot. The G: drive mounts asynchronously — note: this reproduces on network shares, USB disks, and virtual/mapped drives. A plain local NVMe partition (always immediately available at boot) will not reproduce it.
3. Open VS Code before the drive finishes mounting
4. Claude Code hangs for 60 seconds then errors with Subprocess initialization did not complete within 60000ms

Note: this is a distinct variant of #37430 — that issue covers manually-added additionalDirectories; this one is triggered by paths that Claude Code itself wrote during a previous session. We believe the primary trigger is permission allow rules (e.g. "Read(//g/projects/work/**)") but additionalDirectories pointing to the same drive may also contribute — both are candidates and both should be covered by the fix.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_n/a — path becomes unreachable after reboot, not after an update_

Claude Code Version

2.1.183 (Claude Code)

Platform

VS Code Extension

Operating System

Windows 11 Pro

Terminal/Shell

PowerShell

Additional Information

The Read(//g/...) POSIX-style paths are written automatically by Claude Code — the user never manually edits settings.json. After finishing a session that used a non-C: drive, those paths remain as standing permissions and silently cause the next post-reboot startup to hang. The user has no breadcrumb pointing toward the settings file as the cause.