Windows: timed-out `shell_command` leaves descendant `where.exe` processes running

Summary

On Windows, a timed-out shell_command that launches recursive where /r searches via cmd /c can leave descendant where.exe processes running after the task has already moved on.

Those residual processes continue scanning large directories, causing sustained CPU usage, extra disk activity, and noticeable heat on laptops/desktops. This looks like a Windows process-tree cleanup bug, not just an expensive search strategy.

Observed On

• Codex client version: 0.116.0
• OS: Windows
• Command shape:
• cmd /c where /r %USERPROFILE% *keyword*
• cmd /c where /r %LOCALAPPDATA% *keyword*
• cmd /c where /r %USERPROFILE% *.yaml
• Tool timeout: 30000 ms

Reproduction

1. Ask Codex to locate config/artifact files on Windows without giving an exact path.
2. Let Codex fall back to a broad recursive search under %USERPROFILE% or %LOCALAPPDATA%.
3. Allow the tool call to hit its timeout or let the turn proceed before the recursive scan finishes.
4. Check for residual processes with Get-Process where or Task Manager.

Expected Behavior

• When a shell_command times out, the full spawned process tree should be terminated.
• After the task moves on, no descendant search process should continue scanning in the background.

Actual Behavior

• Codex launches cmd /c where /r ....
• The command exceeds its useful lifetime.
• Descendant where.exe processes remain alive and continue scanning after timeout/task progression.
• CPU usage and system heat remain elevated until those processes finish or are killed manually.

Sanitized Evidence

Sanitized log excerpt from %USERPROFILE%\.codex\log\codex-tui.log:

ToolCall: shell_command {"command":"cmd /c where /r %LOCALAPPDATA% *keyword*","workdir":"%USERPROFILE%","timeout_ms":30000}
ToolCall: shell_command {"command":"cmd /c where /r %USERPROFILE% *.yaml","workdir":"%USERPROFILE%","timeout_ms":30000}
ToolCall: shell_command {"command":"cmd /c where /r %USERPROFILE% *keyword*","workdir":"%USERPROFILE%","timeout_ms":30000}

After the turn had already moved on, multiple where.exe descendants were still running and had accumulated many minutes of CPU time during inspection.

Impact

• Sustained background CPU usage
• Extra Defender/disk churn due to large recursive scans
• Laptop/desktop remains unusually hot
• User may believe the machine is idle because the original task already appears complete

Suspected Root Cause

• Broad fallback search strategy on Windows
• cmd /c parent exits or the tool lifecycle advances, but descendant where.exe is not reliably terminated
• Timeout handling appears to clean up the immediate shell but not the full process tree

Suggested Fixes

1. Kill the full process tree for shell_command on Windows timeout/cancellation, not just the immediate parent process.
2. Avoid where /r across %USERPROFILE% and %LOCALAPPDATA% for fuzzy discovery when narrower strategies are available.
3. Prefer bounded alternatives first:

• known install/config paths
• Get-ChildItem with explicit scope/depth
• rg --files / rg -g where available

1. Consider warning or gating high-cost recursive scans over large user directories.