fix: eliminate orphaned process leaks causing OOM kills

[dangtrivan15]

Summary

• Process group kill: kill_process_tree() now uses os.killpg() when the subprocess was started with start_new_session=True, killing the entire process group atomically. This eliminates the TOCTOU race where children get reparented to PID 1 before psutil.children() runs.
• start_new_session=True on all 6 spawn sites: Every subprocess.Popen call (orchestrator, agent manager, dev server manager) now creates a new process group on Unix.
• cli.js process group kill: killProcess() now sends SIGTERM to -pid (the process group) instead of a single PID. Uvicorn is spawned with detached: true.
• Periodic orphan reaper: Background task (Linux only) scans every 60s for chrome/node/esbuild processes orphaned under PID 1 and kills them after a 30s grace period.

Problem

After each agent session, dev server processes (node, npm, vite, esbuild) and Playwright browser instances (chrome, chrome_crashpad) survive as orphans. Over hours, these accumulate to hundreds of processes consuming gigabytes of memory, eventually hitting the container memory limit and triggering OOM kills.

Root cause: kill_process_tree() uses psutil.Process(pid).children(recursive=True) to find children, but between the parent dying and the tree walk executing, children get reparented to PID 1 and are no longer in the tree.

Observed in production: 183 out of 243 processes were orphans (~67 Chrome processes, ~49 dev server processes, ~56 esbuild processes), consuming 4.4 GB growing toward a 10 GB limit.

Test plan

• Run python -m pytest tests/test_process_utils.py -v — verifies process group kill works on children and grandchildren
• Deploy to a container, run agents for several hours, monitor orphan count stays near zero:

  kubectl exec <pod> -- bash -c 'for f in /proc/[0-9]*/status; do ppid=$(grep "^PPid:" $f 2>/dev/null | awk "{print \$2}"); pid=$(grep "^Pid:" $f 2>/dev/null | awk "{print \$2}"); [ "$ppid" = "1" ] && [ "$pid" != "1" ] && echo $pid; done | wc -l'

• Verify memory stays stable via cat /sys/fs/cgroup/memory.current
• Verify Windows is unaffected (process group changes are Unix-only)

Fixes #164, fixes #197.

🤖 Generated with Claude Code