buzz-acp leaks ACP agent process trees after cancel_drain_timeout
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Summary
When an ACP agent turn fails with `cancel_drain_timeout`, the spawned agent process tree is never reaped. Repeated failures accumulate orphaned processes until memory pressure becomes significant.
## Environment
- Buzz Desktop v0.5.11
- Windows 11 (build 26200)
- Agent runtime: Hermes Agent v0.20.0 / v0.20.1 via `buzz-acp`
## Observed
After a series of failed agent turns in a single channel:
| Process | Count | Notes |
|--------------------------------|--------|--------------------------------|
| `hermes-acp.exe` | 20 | none exited |
| `python.exe` (hermes children) | 42 | roughly two per `hermes-acp` |
| `buzz-acp.exe` | 3 | |
| Combined resident memory | 789 MB | |
All 20 `hermes-acp` processes were spawned in a five-second burst (06:09:19–06:09:24) under a single `buzz-acp` parent, and none ever exited.
Each failing turn ended with:
```
Turn error - cancel_drain_timeout: Agent did not stop within 5s after
cancellation; the agent process is being replaced.
```
The replacement process is created as stated, but the process being replaced is not terminated — so each failed turn leaks one tree.
## Expected
On `cancel_drain_timeout`, `buzz-acp` should escalate to terminating the agent's full process tree (children first) before spawning a replacement, rather than abandoning the previous process.
## Impact
Users hitting any persistent agent-side failure accumulate orphaned process trees indefinitely. Recovery currently requires manually enumerating and killing descendant trees outside Buzz. The leak also makes the underlying agent failure harder to diagnose, because each retry adds another set of processes writing to the same runtime logs.
## Note on scope
The agent-side hang that triggered these cancellations is a separate defect in the Hermes runtime and is filed separately against `NousResearch/hermes-agent`. This report covers only the process lifecycle handling in `buzz-acp`, which is independent of *why* any given agent stops responding — any agent that fails to drain within 5s will leak in the same way.
Contributor guide
Assessment
This issue has not been assessed yet.