[BUG] Hanging find.exe

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Usage: ultracode Model: Opus 4.8 or Fable

1. Subagents ran unscoped find commands via the Bash tool. During two multi-agent Workflow runs (parallel "recon" subagents reading the codebase), some agents tried to locate ABP framework DLLs and source files. Instead of scoping the search to the repo or the NuGet cache (~/.nuget/packages), they ran GNU find from Git Bash's usr/bin with / as the root.
2. On Windows, Git Bash's / is catastrophic to walk. Under MSYS2/Git Bash, / maps to the Git installation root, but paths like /c, /d expose every mounted drive, and the walk crosses into enormous trees (C:\Windows, C:\Users, node_modules everywhere, cloud-synced folders that may trigger on-demand downloads). A single find / -iname x.dll can run for hours.
3. The processes outlived their parents. The subagents finished (or their Bash tool calls timed out — likely at the 2-minute default), the workflows completed, but the spawned find.exe children were never killed. The Bash tool's timeout appears to have abandoned the child processes rather than terminating the process tree. They kept scanning as orphans. The timestamps match exactly when each workflow's agents were active.
4. A related symptom existed before this session: a bash.exe.stackdump file was sitting in the repo root at session start, suggesting Git Bash child-process issues on this machine aren't new.

What Should Happen?

1. Process-tree cleanup on Bash tool timeout/completion (Windows). When a Bash tool call times out or the agent session ends, the harness should kill the entire child process tree (e.g., via Job Objects on Windows), not just the immediate shell. Orphaned children silently consume resources with no visibility to the user or the model.
2. Guardrail for unscoped filesystem scans. find /, grep -r /, etc. are almost never intended on Windows (or anywhere) and could be flagged, sandboxed, or require confirmation — especially for subagents running semi-autonomously, where nobody reviews each command.

Error Messages/Logs

Steps to Reproduce

Environment

• Windows 11 Pro (10.0.26200)
• Claude Code with the Bash tool backed by Git for Windows (GNU find.exe at C:\Program Files\Git\usr\bin\find.exe)
• Observed with subagents (Agent/Workflow runs), but the mechanism should reproduce with a plain Bash tool call

Minimal reproduction

1. In Claude Code on Windows, have Claude run this via the Bash tool (must be Bash, not PowerShell, so Git Bash's GNU find is used):

find / -iname "some-nonexistent-file-xyz.dll"

1. From Git Bash, walking / crosses into all mounted drives (/c, etc.), so this runs far longer than any tool timeout — often hours.
2. Let the Bash tool call hit its default timeout (120000 ms) and return control to the model.
3. In a separate PowerShell window, check for survivors:

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

1. Expected: the timed-out call's entire child process tree is terminated.

Actual: find.exe keeps running as an orphan, scanning the filesystem and consuming CPU/RAM indefinitely, with no notification to the user or the model.

1. Repeat the call a few times → orphans accumulate, one per leaked call.

Real-world amplified version (what actually happened in this session)

A multi-agent workflow ran 5–6 parallel recon subagents over a .NET repo. Several autonomously ran unscoped searches to locate framework files — e.g. find / -iname Volo.Abp.Core.dll, find / -iname AbpPageModel.cs, find / -path /Volo.Abp.AspNetCore.Mvc.UI.RazorPages -iname *.dll. Across two workflow runs over ~1h40m (12:05–13:47), 7 orphaned find.exe processes accumulated until the user noticed system-wide RAM/CPU drain.

Notes worth including in the issue

• When inspected, the parent bash.exe processes were already gone — only the find.exe grandchildren survived. That points to the harness killing/reaping the shell but not the full process tree (no Job Object / process-group kill on Windows).
• A pre-existing bash.exe.stackdump file in the repo root suggests Git Bash child-process crashes also occur on this machine — a bash crash is a second plausible leak path besides timeout.
• Cleanup that worked: taskkill /F /IM find.exe (an initial Stop-Process pass appeared to lag in the process-list read; taskkill confirmed removal).
• Suggested fixes: (1) kill the entire child process tree on Bash tool timeout/completion — Job Objects on Windows; (2) guardrail or require confirmation for unscoped filesystem scans like find /, especially for autonomously-running subagents.
• Honesty caveat: the timeout-abandonment mechanism is inferred (orphans with dead parents, creation times matching subagent activity windows, commands matching recon behavior) — the exact leak moment wasn't directly observed.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.206

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_