[Bug] Background shells from run_in_background never reaped; no UI to manage leaked processes

Resolved 💬 1 comment Opened Jun 4, 2026 by rozim Closed Jul 8, 2026

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

[]

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗