Bash tool leaks orphaned child processes on Windows timeout (runaway ind / scans accumulate for hours)

Still present on 2.1.237 (this was filed against 2.1.206), and I can add three things the report doesn't cover: user cancellation as a trigger, a pipeline backstop that also fails, and a quantified reason the symptom is so hard to attribute.

1. Cancellation, not just timeout

The tool call was cancelled by me interactively, not timed out:

11:57:12.207Z   tool_use emitted
11:57:14        grep.exe PID 8156 created
11:57:43.470Z   toolDenialKind: "user-rejected"   <- I cancelled here
                session ended, no further entries

29 minutes later, with the session long closed:

grep.exe   PID=8156   parent=18956  DEAD   elapsed=28.4 min   cpu=115s
   cmd: grep.exe -rl SOMESTRING /c/Users/<user>/Downloads /c/Users/<user>/Desktop /c/Users/<user>/Documents
head.exe   PID=9228   parent=13672  DEAD   elapsed=28.4 min   cpu=4s
   cmd: head.exe -50

I ended it manually with Stop-Process -Force at that point. It showed no sign of stopping on its own — it was still actively walking the tree when I killed it (the three roots total ~127,000 files / ~19 GB). Nothing in Claude Code ever reaped it, and the session that spawned it had been closed for half an hour.

2. | head -N does not save you — and the reason is interesting

The original command was:

grep -rl "SOMESTRING" <three big dirs> 2>/dev/null | head -50

That pipeline is supposed to be self-limiting: head exits after 50 lines, the pipe closes, grep dies on SIGPIPE.

It didn't, because both pipeline members were orphaned, not just grep. head stayed alive holding the read end of the pipe open. grep -rl had not yet found 50 matching files, so head sat blocked waiting for more input, grep kept writing to a perfectly live pipe, never received SIGPIPE, and kept walking the tree.

So partial process-tree cleanup is worse than none here: killing only bash.exe leaves a self-sustaining pair. Any bounded-output idiom (| head, | head -n, | sed q) silently loses its bound under this bug.

3. Why it's hard to attribute: the antivirus amplification

The orphan's own CPU is small, which is why nothing looks wrong in Task Manager. Microsoft Defender Performance Analyzer (New-MpPerformanceRecording / Get-MpPerformanceReport), 90-second window while the orphan ran:

| Metric | Value |
|---|---|
| Total real-time scans | 7,314 |
| Caused by the orphaned grep.exe | 7,017 (96%) |
| Total scan duration | 81,523 ms |
| Caused by the orphaned grep.exe | 80,267 ms (98.5%) |

Count TotalDuration MinDuration AverageDuration MaxDuration ProcessPath
----- ------------- ----------- --------------- ----------- -----------
 7017  80266.7981ms    0.0321ms       11.4389ms 1369.3628ms C:\Program Files\Git\usr\bin\grep.exe
   39    600.2009ms    7.1359ms       15.3897ms   29.0021ms ...\claude-code\2.1.237\claude.exe
  120    344.4870ms    0.2074ms        2.8707ms   60.3683ms C:\Program Files\nodejs\node.exe

MsMpEng.exe held a steady 89–118% of one core across 12 consecutive samples, never dropping below 88.8%. Once the orphan was killed it fell to 2–17%.

The orphan itself used only 3–14% of a core — but by opening ~78 files/sec it forced Defender to spend ~11.4 ms per file (up to 1,369 ms on a large DLL). A ~10x–100x amplification. The visible symptom is a pegged core belonging to MsMpEng.exe and a laptop fan at full speed, with no running task and no open session to explain it. Correlating Defender's CPU against other processes' file I/O shows no relationship (r = 0.12–0.20), because the driver is a process nobody is looking at.

Environment

• Claude Code 2.1.237, desktop app (entrypoint: claude-desktop)
• Windows 11 Pro 10.0.26200, AMD64
• Git for Windows 2.55.0.windows.4, GNU grep 3.0
• permissionMode: auto

Detection one-liner for anyone else hitting this:

$a = Get-CimInstance Win32_Process; $l = @{}; $a | % { $l[$_.ProcessId] = 1 }
$a | ? { $_.Name -in 'grep.exe','head.exe','bash.exe','find.exe' -and -not $l[$_.ParentProcessId] } |
  Select Name, ProcessId, CommandLine

Agreed on the suggested fix — a Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE would close all three triggers (timeout, cancellation, session teardown) at once.

Still present on 2.1.272 (filed against 2.1.206, confirmed on 2.1.237 above). Four things to add, the second of which may be the most useful: the PowerShell tool on the same machine does not have this bug, so a working implementation already exists in-product.

1. Controlled A/B: Bash tool leaks, PowerShell tool does not

Same grandchild binary, same machine, same session, same 10s timeout. Only the tool differs.

Bash tool:        /c/Program\ Files/Git/usr/bin/sleep.exe 601
PowerShell tool:  & 'C:\Program Files\Git\usr\bin\sleep.exe' 602

The Bash tool reported Exit code 143 / Command timed out after 10s. The PowerShell tool moved its command to a background task, which I then ended via the harness's own stop.

State afterwards:

  PID Parent ParentAlive Args Started
  --- ------ ----------- ---- -------
22064  64932       False  601 10:10:40    <- Bash tool child: ORPHANED
22308  46364        True  602 10:10:55    <- PowerShell tool child: parent still tracking it

After stopping the PowerShell task, +8s:

  PID Parent ParentAlive Args Started
  --- ------ ----------- ---- -------
22064  64932       False  601 10:10:40    <- still alive, 8 minutes later
                                          <- 602 is gone: tree reaped

So the Bash tool believes it terminated the command (exit 143) while the grandchild keeps running, and the PowerShell tool tears the tree down correctly. Whatever the PowerShell path does on teardown is the behaviour the Bash path needs.

2. The detection one-liner in the comment above over-flags, and the false positives are live work

The published detector keys on a dead parent alone:

$a | ? { $_.Name -in 'grep.exe','head.exe','bash.exe','find.exe' -and -not $l[$_.ParentProcessId] }

On this machine that flagged four processes that were not orphans. All four were in-flight children of tool calls that were still running, age 0.00h. The Bash-tool wrapper exits before its own child does, so every live Bash tool call looks orphaned for its entire duration.

That matters for anyone building a reaper on top of this: a reaper keyed on dead-parent alone kills the session's own running work. The predicate needs age as well, and ideally sustained core fraction. Measured across 48 claude.exe on this box: median core fraction 0.000, max 0.055, while every confirmed orphan sat at 0.74-0.98. The band between 0.06 and 0.74 was empty, so the split is clean rather than a threshold picked by hand.

A narrower discriminator that held perfectly here: binary path. All 9 orphans were under C:\Program Files\Git\. Zero pwsh.exe orphans, consistent with section 1.

3. Stop-Process worked here, and verification timing is a trap

The original report notes taskkill /F /PID and Stop-Process both failing, with only Win32_Process.Terminate working. On Git for Windows 2.55.0.windows.5 / Claude Code 2.1.272, Stop-Process -Force killed all 7 orphans successfully. Possibly version-dependent, so worth trying before reaching for WMI.

The trap is how long teardown takes. Checking too early reads as a failed kill:

+10s   PID 36536   Get-Process: ALIVE   Win32_Process: ALIVE
+16s   PID 36536   Get-Process: gone    Win32_Process: gone      (0.00 CPU-s accrued in that window)

Both instruments agreed it was alive at +10s, against a control PID that read correctly. A find walking a filesystem does not die instantly. Use accrued CPU over the interval, not liveness, as the discriminator -- a process mid-teardown accrues nothing, while a surviving one keeps burning.

4. Unbounded memory is a second failure mode, distinct from CPU burn

Not every orphan is a CPU story. This one:

grep.exe -a -o -E 'Ti=\(e\)=>.{0,14000}' C:/Users/<user>/.local/share/claude/versions/2.1.272

reached 3.45 GB RSS, growing at a measured 1.1 MB/s, on a machine with 3.0 GB free of 31.7 GB. grep -o with a wide match window buffers each match, so an orphaned one climbs until it exhausts memory. Killing it returned free RAM from 3.0 GB to 4.6 GB immediately.

Rate of accumulation under concurrent sessions

This machine runs many concurrent Claude Code sessions. Seven orphans of this exact shape were cleared about an hour before my sweep -- 126.2 CPU-hours combined, measured by another session on the same box. Four more had appeared within the following 45 minutes, three of them find / variants. Survivors from earlier were 37, 51 and 51 hours old.

So on a multi-session setup this does not reach a steady state. It accumulates roughly as fast as sessions issue searches, and nothing in the product ever reaps them.

Environment

• Claude Code 2.1.272, desktop app
• Windows 11 Pro 10.0.26200, 20 logical CPUs, 31.7 GB RAM
• Git for Windows 2.55.0.windows.5, GNU grep 3.0
• Leaked binaries all under C:\Program Files\Git\usr\bin\ and C:\Program Files\Git\mingw64\bin\

Agreed on the Job Object fix. Given section 1, it may be worth checking what the PowerShell tool path already does on teardown and applying the same thing to the Bash path.

Hit this again today and isolated the root cause. It is narrower than "find / is slow", and that makes it fixable.

The handle pump is not /. It is three registry mounts under /proc.

Git Bash / is C:\Program Files\Git, and the MSYS2 runtime mounts the entire Windows registry there as filesystem trees: /proc/registry, /proc/registry32, /proc/registry64. Walking them opens a kernel handle per registry key, and HKEY_CLASSES_ROOT alone is effectively unbounded.

Paired arms, same find.exe, handle count sampled every 3 seconds:

| command | handles at 3/6/9/12/15s | output lines | exits? |
|---|---|---|---|
| find /proc/registry | 7,619 -> 15,590 -> 22,185 -> 26,594 -> 30,471 | 2,202 | no |
| find /proc | 8,643 -> 16,082 -> 23,448 -> 32,342 -> 39,782 | 3,300 | no |
| find /proc -maxdepth 2 | n/a | 302 | yes, immediately |
| find /proc with all 3 registry mounts pruned | flat | 3,866 | yes, immediately |
| find / (first 15s) | 205 -> 206 -> 205 -> 206 -> 206 | 285,839 | still in the real filesystem |

Two things worth pulling out of that table.

find / looks healthy for a long time. It stays flat at ~205 handles while it walks the real filesystem, because /proc sorts after mingw64 and usr. It only becomes the runaway once it descends into /proc. So a short reproduction attempt can easily miss it.

Pruning /proc/registry alone does not work. I tried exactly that and the scan fell straight into /proc/registry32 and kept leaking, at almost the same rate. It has to be the whole of /proc, or all three mounts named explicitly.

This also explains a detail from an earlier run that had not made sense: a runaway find.exe at 95 percent of one core showed 4 total disk read operations. It was not reading the disk at all. The registry is in memory.

Workaround, verified:

find / -path /proc -prune -o -name '<pattern>' -print

Suggested fix on the tool side: the Bash tool could prune /proc by default for MSYS find, or the Windows setup notes could say that / is not the filesystem root here and that /proc must be excluded. Either would have prevented every instance of this I have seen.

Separately, and this is the half that turns a slow command into a machine-wide outage: a descendant of the Bash tool's bash.exe is not reaped when the wrapper dies. I measured that directly and wrote it up on #90672 rather than repeat it here. Without that second defect these scans would end with the session instead of running for hours.

For scale, on a 20-core / 32 GB Windows 11 box: two orphaned find and three orphaned grep reached 4,183,509 machine-wide handles with paged pool at 4,620 MB. A test suite that normally finishes in 10 seconds took 26 minutes. Killing the five orphans brought handles to 255,190.