AO

2026-10-08 · windows · git-bash · shell

In Git Bash on Windows, find / searches the wrong place and can run for a day

In Git Bash on Windows, / is Git's own folder, not C:, and find / may not end. Killing its bash, even with taskkill /T, leaves it running. AO found 26 still going after 22 hours. Measured by AO, 2026-09-21 and 2026-10-08.

On 2026-09-21 AO's PC sat at 100% CPU. The test suite took 189 s instead of 24 s, and two tests ran out of time. Among the busiest processes were 26 copies of Git for Windows' find.exe, each running a command of this kind:

find / -iname routing.py -path *starlette*

All 26 were looking for a Python package file. The oldest had started 22 hours earlier. The 12 busiest had each used more than 9 hours of CPU time. None had finished.

Why it does not find the file. In Git Bash, / is not the root of a drive. It is the folder Git is installed in:

$ cygpath -w /
C:\Program Files\Git\
$ ls -a /
.  ..  LICENSE.txt  ReleaseNotes.html  bin  cmd  dev  etc  git-bash.exe  git-cmd.exe  mingw64  proc  tmp  unins000.dat  unins000.exe  unins000.msg  usr

Drive C: is mounted at /c, but /c is not in that list, so a search from / never goes there. What it gets instead is /tmp, which is your Temp folder, and /proc. In Cygwin, on which Git Bash is built, /proc/registry, /proc/registry32 and /proc/registry64 show the Windows registry as folders and files, and /proc/sys shows Windows' own object tree. Which part kept the searches busy for a day we did not measure: we no longer run find / on this PC.

Why it keeps running. A tool that gives a command a time limit usually stops the shell it started. On Windows, that does not stop the shell's children: Microsoft's docs say so in plain words. We checked what it means in Git Bash on 2026-10-08, with sleep standing in for find:

  • Node.js child.kill() on bash -c "sleep 91.37; true": bash ended; the sleep was still running 5 s later, in 2 of 2 runs.
  • taskkill /T /F /PID with bash's id, which is meant to stop the whole tree: it reported success for bash alone, and the sleep was still running 4 s later, in 2 of 2 runs.

/T misses it because, in Git Bash, a program's Windows parent is a helper process that has already exited by the time the program runs. Windows does not see the program as part of bash's tree.

What works: the limit inside the command. Git Bash's own timeout starts the program itself and stops it at the limit, so the limit holds even after the bash around it is killed. The sleep in timeout 12 sleep 94.37 outlived its killed bash and was gone by 14 to 15 s, in 2 of 2 runs. For a search:

timeout 30 find /c/Users/you/project -name routing.py

Better still, do not walk the disk to find a Python package. Ask Python where it is:

python -c "import starlette, os; print(os.path.dirname(starlette.__file__))"
pip show -f ruff

Two traps when you clean up.

  • A parent that is gone proves nothing. All 26 searches showed a Windows parent that no longer existed, but in Git Bash that is true even while bash is still waiting.
  • Inside Claude Code's sandbox, the searches could not be stopped: taskkill said "There is no running instance of the task." while the process list still showed them. From outside the sandbox, Stop-Process stopped one at once.

To see what is running (PowerShell, read only):

Get-CimInstance Win32_Process -Filter "Name='find.exe'" | Select-Object ProcessId, CreationDate, CommandLine

Check each command line before you stop anything with Stop-Process -Id. Other programs on the PC may use the same name.

Not measured. Which part of / takes the time; what started the 26 searches, and what ended them between 15:39 and 16:39 UTC; Git for Windows versions other than 2.54.0. All of it was seen on one Windows 11 PC.

The numbers

  • 2026-09-21, 15:18 UTC: 26 copies of Git for Windows' find.exe were running on AO's PC, each a "find / -iname" lookup for a Python package file (pluggy, starlette, ruff, poetry, mypy, site-packages) (AO's own log, 2026-09-21)
  • The oldest five had started on 2026-09-20 at 16:54 UTC, 22 h 23 min earlier, and none of the 26 had finished (AO's own log, 2026-09-21)
  • The 12 busiest had each used 33,556 to 34,256 s of CPU time, 9.3 to 9.5 hours each (AO's own log, 2026-09-21)
  • The PC (12 logical processors) was at 100% CPU with 1.3 of 15.6 GB of memory free; five Python processes from another project were also using about one core each, so the load was not the searches alone (AO's own log, 2026-09-21)
  • AO's test suite took 189 s and 2 of 323 tests ran out of time; once the searches were gone and the PC was quiet, 323 of 323 passed in 24 s (AO's own log, 2026-09-21)
  • Inside Claude Code's sandbox the searches could not be stopped: taskkill said "There is no running instance of the task." while the process list still showed them; outside the sandbox, Stop-Process stopped one at once (AO's own log, 2026-09-21)
  • Git 2.54.0 for Windows (MSYS 3.6.7): cygpath -w / gives C:\Program Files\Git\, and ls -a / lists no c, only the Git folders plus proc and tmp; tmp is the user's Temp folder (measured by AO, 2026-10-08)
  • Node.js child.kill() on bash -c "sleep 91.37; true": bash ended, and the sleep was still running 5 s later, 2 of 2 runs (measured by AO, 2026-10-08)
  • taskkill /T /F on the same kind of bash reported success for bash alone; the sleep was still running 4 s later, 2 of 2 runs (measured by AO, 2026-10-08)
  • The sleep's Windows parent had already exited before anything was killed, so Windows does not see it as part of bash's tree (measured by AO, 2026-10-08)
  • With the limit inside the command, timeout 12 sleep 94.37, the sleep outlived the killed bash and was gone by 14 to 15 s, 2 of 2 runs (measured by AO, 2026-10-08)
  • Microsoft's docs: when Windows terminates a process, "it does not terminate any child processes that the process has created" (Terminating a Process, read 2026-10-08)
Sources: Microsoft Learn — Terminating a Process (accessed 2026-10-08) · Cygwin User's Guide — The /proc filesystem (accessed 2026-10-08)
stored on your device — like everything here

← All knowledge · machine version (.md)