Windows: per-second statusLine bash spawns turn the MSYS add_item/errno 1 race into a permanent outage of every Bash call

[69Jesse]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet ([ Bash shell crashes on every invocation on Windows — MSYS2 fatal error (exit code 3221225477)] #30165 is the same symptom, but it was auto-closed as inactive and locked without a root cause; this report has the root cause and fixes Claude Code can make on its own side)
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

On Windows, every Bash tool call, the status line, and git's credential helper all start dying with

Exit code 5
0 [main] bash (9800) C:\Program Files\Git\bin\..\usr\bin\bash.exe: *** fatal error - add_item ("\??\C:\Program Files\Git", "/", ...) failed, errno 1

after a 15 second hang. Once it starts it doesn't stop until every MSYS process on the machine is gone, which in practice means a reboot. #30165 reported the symptom. This is the mechanism, and why Claude Code's own status line polling is what turns a rare MSYS race into a permanent outage.

The MSYS bug (msys2-runtime, same code in 3.4.7 and 3.6.10; tracked as git-for-windows/git#6368, fix pending in msys2/msys2-runtime#333). Every MSYS process (bash.exe, sh.exe, ...) maps a per-user shared memory section at startup. The first one to map it builds the mount table under a spinlock that gives up after 15 s and lets the waiter initialise anyway. The section only exists while some MSYS process has it mapped. If the initialiser dies inside the critical section (a process tree being terminated while a shell is starting, or an init that takes more than 15 s), the lock is stuck at -1. Every newcomer then waits 15 s, re-runs mount_info::init on the already built table, and dies in create_root_entry with EPERM, without ever resetting the lock.

Why Claude Code makes it permanent. On Windows a statusLine command runs as bash.exe -c "<command>" through Git Bash, once per refresh, per session. With refreshInterval: 1 and three sessions open that is three fresh MSYS cold starts every second, and each crashing victim spins for 15 s before it dies. So there is always a new holder alive when the last one dies, and the poisoned section is never released. I checked this by enumerating processes with msys-2.0.dll loaded: nothing but 15-second-old bash processes, all -c "node ~/.claude/statusline.mjs", for as long as I watched. With nothing long-lived around, the section is also being torn down and rebuilt many times a minute, so every rebuild is a fresh chance to lose the race in the first place.

Downstream: git's credential.helper = manager runs through sh -c, so HTTPS fetch/push fail with "could not read Username"; every Bash tool call fails; hooks in shell form fail.

What Should Happen?

Any one of these would fix it from Claude Code's side, without waiting for the runtime patch:

1. Keep one long-lived MSYS process alive while any session is running (for example usr\bin\sleep.exe infinity, non-elevated). The shared section then gets initialised once, by a process nothing is racing, and every later bash start takes the fast path (locktest == wanted_val, no spinning). This is the usual CI workaround for this bug (keep a common MSYS parent alive), and it's what I run locally now as a logon task: cold starts went to 28 to 37 ms and it hasn't come back.
2. Let statusLine run in exec form, with the args array hooks already support, so a node or powershell status line doesn't need a bash wrapper on Windows at all. The 2.1.278 schema only accepts type, command, padding, refreshInterval and hideVimModeIndicator.
3. Recognise the fatal and recover: when a spawned bash exits with this exact message, kill every process with msys-2.0.dll loaded (in the poisoned state all of them are already doomed) so the section is released, instead of retrying into the same wall every second.

Steps to Reproduce

Hard to trigger on purpose from outside the DLL, but this shape reliably produces it:

1. Windows 11, Git for Windows, a statusLine with refreshInterval: 1, three or more sessions open.
2. Run an orchestration that terminates worker sessions' process trees while they are busy (shells starting and stopping), under CPU load.
3. At some point one bash start dies with the add_item ... errno 1 fatal after a 15 s hang, and from then on every one does. Get-Process | ? { $_.Modules.ModuleName -contains 'msys-2.0.dll' } shows nothing but young bash processes.
4. Kill every MSYS process (or reboot) and it works again. Stop the status line churn and the poisoned state clears within 15 s on its own; keep it running and it never does.

Claude Code Version

2.1.278

Operating System

Windows 11 Pro 10.0.26100, not domain-joined (so this is not the slow AD lookup variant in git-for-windows/git#6368)

Terminal/Shell

Windows Terminal, Git for Windows 2.42.0.windows.2 (msys2-runtime 3.4.7)

Additional Information

Related: #30165 (same symptom, closed and locked), git-for-windows/git#6368 (mechanism, slow lookup trigger), msys2/msys2-runtime#333 (runtime fix, waiting on upstream submission to cygwin-patches).

[69Jesse]

One addition from a recurrence, relevant to which of the three fixes is worth doing.

Option 3 (recognise the fatal and self-heal by killing MSYS processes) is harder than it sounds, for a reason that comes straight from the status line. Releasing the poisoned section needs a moment with zero processes mapping it, and while the status line keeps spawning bash once a second per session, that moment has to be forced against the spawner. A one-shot kill of everything with msys-2.0.dll loaded failed 8 attempts in a row on my machine, because by the time the old spinners were dead (module enumeration takes seconds) new status-line bash processes had already mapped the section again. What worked was a ~100 ms kill sweep for 3 s, matching by executable path, followed immediately by starting a long-lived anchor process. Claude Code could do that, but it would have to pause its own status-line rendering across every session while it does, which is awkward.

Options 1 (keep one long-lived MSYS process alive) and 2 (exec-form args for statusLine, so no bash wrapper on Windows) avoid the problem instead of racing it, and either one is a small change. Of the two, 1 also protects the Bash tool and shell-form hooks, not just the status line.