Windows Bash tool fails with 'Directory \drivers\etc does not exist' on every command

Description

The built-in Bash tool (Git Bash integration) fails on every invocation with:

Directory \drivers\etc does not exist; exiting
If directory name is garbage you need to update your msys package

This happens before any user command runs — the tool errors out immediately on the simplest possible command (e.g. echo hi).

Environment

• Claude Code version: 2.1.260
• OS: Windows 11 Pro (build 10.0.26200)
• Git for Windows version: 2.55.0.windows.5 (freshly reinstalled from the official installer)
• Machine: HP ProBook 430 G8

What I ruled out

• Not a Windows problem: C:\Windows\system32\drivers\etc exists and is accessible normally.
• Not a Git installation problem: running the exact same underlying binary (C:\Program Files\Git\bin\bash.exe -c "echo hi") directly — outside Claude Code, via PowerShell's Process.Start with a minimal custom environment block (only PATH, TEMP, TMP, USERPROFILE, HOMEDRIVE, HOMEPATH set, everything else stripped) — runs fine every time.
• Not the sandbox flag: reproduces identically with dangerouslyDisableSandbox: true passed to the tool call.

How this started

This began appearing after a separate, unrelated fix: Git Bash was completely unable to fork child processes on this machine (fork: retry: Resource temporarily unavailable, exit code 0xC0000142), traced to Windows' system-wide "Force randomization for images (Mandatory ASLR)" exploit-protection setting conflicting with the MSYS2 runtime's fork emulation. The fix was adding per-program Exploit Protection overrides (Mandatory ASLR = Off) for bash.exe, dash.exe, and sh.exe under C:\Program Files\Git\. That fully fixed forking when Git Bash is run directly (confirmed working via PowerShell-invoked bash.exe). Along the way, Git itself was also uninstalled and freshly reinstalled (same version, 2.55.0.windows.5) while chasing the fork bug.

After all that, directly-invoked Git Bash works perfectly — but Claude Code's own Bash tool now fails with the \drivers\etc error shown above, every single time, unrelated to the fork issue.

Why I suspect this is Claude Code–specific

Since the identical binary works fine when launched with a manually-constructed minimal environment outside Claude Code, but fails inside Claude Code's Bash tool (sandboxed or not), the difference looks like it's in how Claude Code's Windows Bash tool spawns bash.exe — possibly the process token, environment block construction, or working-directory setup used specifically by that tool's internals.

Request

Could someone with visibility into the Windows Bash tool's process-spawning code take a look at what differs from a normal CreateProcess/.NET Process.Start call? Happy to provide more diagnostics if useful.