Windows: superseded PowerShell recursive searches keep consuming CPU

Summary

On Windows, Claude Code left two CPU-active pwsh.exe tool children running after it had already moved on to newer work. They were not OS zombies: both were still recursively scanning the workspace and consuming CPU, but their original tool calls no longer appeared relevant to the active Claude workflow.

Environment

• Windows 11
• Claude Code launched as claude.exe
• Large local workspace with .claude/worktrees (35 worktrees; 29 contained node_modules)

What happened

Two direct pwsh.exe children of one active claude.exe parent were still running:

Get-ChildItem -Recurse -File -Path scripts,.claude -Include *.mjs,*.js |
  Select-String ...

and a similar .claude,scripts recursive search.

Both searches traversed .claude/worktrees, including many node_modules directories. The Claude parent later spawned a newer child for unrelated work, but the old PowerShell children kept running. The expected completion/handoff output for the old calls was absent.

During a 10-second sample, the two old children consumed approximately 5.72 CPU seconds and 1.66 CPU seconds respectively. This caused visible desktop slowdown; Defender and DWM load increased secondarily.

Expected behavior

When a tool invocation becomes superseded, cancelled, or no longer awaited, Claude Code should terminate or reap its still-running child-process tree. For recursive file searches, it should also avoid unbounded PowerShell Get-ChildItem -Recurse through .claude/worktrees / node_modules (for example, prefer a bounded ignore-aware search).

Workaround

I manually terminated only the two stale pwsh.exe child trees. They were read-only searches, and the newer Claude work continued.

Could the tool-process lifecycle be checked for cases where Claude advances to a new action while the prior PowerShell child remains CPU-active?