[Bug] Working directory falsely reported as "deleted" on Windows when cwd is an ImDisk ramdrive — every shell call blocked by recovery loop

Preflight

• [x] Searched existing issues (none match this scenario)
• [x] On latest Claude Code

Environment

• OS: Windows 11 Pro (10.0.22621)
• Shells affected: PowerShell tool (PowerShell 7+) and Bash tool
• Model: claude-opus-4-7[1m]
• CWD type: ImDisk virtual ramdrive mounted at V:\ (also accessible from WSL at /mnt/v)

What happens

When Claude Code is launched with the cwd on an ImDisk ramdrive, every subsequent PowerShell or Bash tool call fails with:

Working directory "V:\" was deleted; shell cwd recovered to "C:\Users\<user>". Re-issue your command (it will run from the recovered directory).

Re-issuing does not help — the same notice fires for the next call, and the next, indefinitely. The session is effectively unable to run any shell command for the rest of its lifetime. Read, Edit, Write, and Glob/Grep continue to work because they don't hit the cwd-liveness gate.

Root cause (hypothesis)

The ramdrive is not deleted. It is fully mounted and accessible:

• Test-Path V:\ → True
• Get-PSDrive V → present (FileSystem provider)
• [IO.Directory]::Exists('V:\') → True
• /mnt/v from WSL → fully readable/writable
• Get-Volume / Win32 volume enumeration (FindFirstVolume, GetLogicalDrives filtered by volume info) → does not list V:\

ImDisk ramdrives surface through the Windows filesystem layer (PSDrive / Test-Path) but not through the Win32 volume-enumeration APIs. The harness's cwd-liveness probe appears to use a volume-enumeration check, which misclassifies the still-valid ImDisk drive as "deleted" and triggers the recovery path on every shell invocation.

Reproduction

1. On Windows, create an ImDisk ramdrive at V:\ (e.g. imdisk -a -s 1G -m V: -p "/fs:ntfs /q /y").
2. cd V:\ and launch Claude Code.
3. Ask the model to run any shell command (PowerShell or Bash tool).
4. Observe the recovery-loop notice; every subsequent shell call fails with the same message.

Impact

• A session started from an ImDisk ramdrive is unable to run any shell tool for its entire lifetime — no git, no builds, no validation, no test runs.
• Restarting from a regular drive (C:\, D:\, etc.) works around it, but the user loses the session.
• Likely affects other virtual-disk technologies that bypass the Win32 volume layer (e.g. some VHD/loopback mounts, SUBST'd drives in certain configurations) — worth checking.

Suggested fix

Fall back to Test-Path / [IO.Directory]::Exists(cwd) (or the equivalent GetFileAttributes / CreateFile probe) when volume enumeration comes up empty. The PSDrive/FS-layer probe is the canonical "is this path usable?" check on Windows and correctly handles ImDisk and similar virtual filesystems. If recovery is still desired in any case, it should fire at most once per session — repeating it on every shell call traps the session.

Workaround

Launch Claude Code from a directory on a physical/conventional drive.