Grep/Glob rg subprocess becomes permanently unkillable when it hits a Google Drive File Stream (Dokan) driver deadlock
Environment
- Claude Code CLI, running from a folder synced with Google Drive for desktop (mount:
C:\Users\<user>\Google Drive Streaming\...) - Windows 11 Pro, build 26200
- Google Drive for desktop v130.0.2.0
Symptom
When the Grep/Glob tool searches files in a directory synced with Google Drive for desktop, the search subprocess (command line like rg --no-config --files --hidden ..., running as the same claude.exe binary re-exec'd with different args, not a separate rg.exe) can hang indefinitely in a single syscall, with near-zero CPU.
Root cause is upstream: Google Drive for desktop uses a Dokan-based virtual filesystem driver with a known deadlock class (unhandled "GetInfo" info class 77 -> dispatch queue stalls -> both I/O and UI threads of GoogleDriveFS.exe deadlock; matches dokan-dev/dokany #930 and #625). When the rg search hits this, the thread blocks inside the kernel/driver and cannot be terminated by any user-mode API -- confirmed Stop-Process -Force and taskkill /F both fail silently (no error, process stays alive) even when run elevated as Administrator.
Impact
In a single day of normal usage (repeated searches in a Drive-synced folder), 14 orphaned, permanently-stuck search processes accumulated, the oldest alive for ~12 days, each holding ~130 handles and 100-160MB RAM never released. They survive logoff/logon; only a full OS reboot clears them.
Note: this is a different issue from #31548 (which is about the VSCode extension leaving file locks that block app updates -- unrelated root cause, no Google Drive involved).
Suggestion
Since the root cause is a third-party driver bug outside Anthropic's control, the actionable fix on the Claude Code side would be a timeout/watchdog on Grep/Glob search subprocesses: if a search hasn't completed within N seconds (e.g. 30-60s), treat it as failed/retry instead of waiting indefinitely for a result that may never come. This would prevent a single stuck filesystem call (on Google Drive, and potentially other cloud-sync drivers like OneDrive/Dropbox with similar issues) from silently accumulating unkillable zombie processes over time.