Reference-file lookups spawn orphaned find processes that pin CPU at 100% (Windows/Git Bash)

Author: Docrichards1Created Aug 20, 2026Updated Aug 20, 2026

Environment: Windows 10, Claude Code CLI, Git Bash (C:\Program Files\Git\\\usr\bin\find.exe)

What happened: During /seo audit runs (specifically the seo-local sub-skill), several sub-agent passes reported failures like:

  • "the skills/seo/references/local-schema-types.md reference file was not successfully loaded (glob search timed out)"
  • "The background grep for local repo references isn't essential to this finding"

These look like a recursive file search (find/grep-based) scoped too broadly — plausibly searching from the user's home directory rather than being scoped to the plugin's own skills/seo/references/ directory. On Windows/Git Bash, when the tool call that spawned the search times out, the underlying find.exe process is not reliably terminated. In this session, 4 orphaned find.exe processes were found still running 45+ minutes later, each consuming ~100% of a CPU core, discovered only because the user noticed system-wide CPU load.

Impact: Silent resource leak — no error surfaces to the user, and the process(es) run indefinitely until manually killed.

Suggested fix:

  1. Scope reference-file lookups to the plugin's own install directory rather than a broad/home-relative search.
  2. Ensure any subprocess spawned for file search is killed when its parent tool call times out (process-group kill, not just abandoning the handle).
  3. Consider a lighter-weight file existence check (direct path read) instead of find/glob for known, fixed reference paths.