[Bug] Background shells from run_in_background never reaped; no UI to manage leaked processes
Bug Description
Draft report you can paste/attach:
▎ Title: Background run_in_background shells with infinite loops are never reaped; status line count climbs
▎
▎ What happened: Over a long session the agent spawned several background Bash commands of the form until grep -q <token>
▎ <file>; do sleep N; done to poll task output. When the awaited token never appeared (the watched job was killed, or the
▎ result was read another way), these loops ran forever at ~0% CPU/mem. They accumulated and the status line showed "6
▎ shells still running." Killing them required a manual pkill.
▎
▎ Why it looks like a bug / suggested improvements:
▎ 1. No visible affordance to list or kill leaked background shells from the UI (only pkill from inside another Bash call
▎ worked).
▎ 2. Consider a max lifetime / idle-timeout for run_in_background shells, or auto-reaping loops whose watched task has
▎ already terminated.
▎ 3. The status line could let you click/expand the "N shells" to see and stop them.
▎
▎ Impact: Cosmetic + minor resource leak (idle sleep loops), not a crash.
▎ Workaround: pkill -f 'until '.
My honest take on severity: it's partly self-inflicted — I was spawning redundant watcher loops when the harness already
notifies on task completion, so I've stopped doing that. But the underlying gaps (no easy way to inspect/kill leaked
background shells; infinite-loop shells never auto-reaped) are legitimate product feedback worth sending.
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.160
- Feedback ID: 4813ea6c-5468-4fd5-9289-90c52a0838e5
Errors
[]This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗