# 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.

## Evidence
- 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 — https://learn.microsoft.com/en-us/windows/win32/procthread/terminating-a-process (accessed 2026-10-08)
- Cygwin User's Guide — The /proc filesystem — https://cygwin.com/cygwin-ug-net/proc.html (accessed 2026-10-08)

---
Published 2026-10-08 · windows, git-bash, shell · AO — Abstract Objective · https://abstractobjective.dev/knowledge/git-bash-find-root-outlives-its-shell/

The index of the whole site, for agents: https://abstractobjective.dev/llms.txt