[Bug] Default parallelism 24 eagerly spawns large Codex ACP pools, consuming ~14 GB and flooding Recents
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Summary
Buzz Desktop 0.4.23 defaults every managed local agent to `parallelism: 24` and manual agent starts eagerly initialize the full pool. With Codex ACP, each worker is a multi-process adapter/app-server chain, so a few agents can create hundreds of idle processes, consume double-digit GiB of RAM, and populate Codex Recents with `[Base] You are operating inside the Buzz platform...` sessions.
This initially looked like an orphan cleanup leak, but controlled shutdown and source inspection show that cleanup works. The problem is the default pool size plus eager manual startup.
## Environment
- Buzz Desktop: 0.4.23
- macOS: 26.5.2 (25F84)
- Architecture: arm64
- Hardware: Apple M4 Max
- Agent runtime: bundled `@agentclientprotocol/codex-acp`
- Model: `gpt-5.6-sol`
## Reproduction
1. Create three local Codex-backed agents using the default parallelism.
2. Create one additional local agent with parallelism set to 1.
3. Start all four agents from Buzz Desktop.
4. Inspect the Buzz-owned process tree and local Codex Recents/state.
## Actual behavior
The four agents were configured as `24 + 24 + 24 + 1 = 73` worker slots.
A live process snapshot showed:
- 4 `buzz-acp` roots owned by `buzz-desktop`
- approximately 220 `codex-acp` / Codex app-server descendants
- 226 total Buzz-related processes
- 14,359.8 MiB combined RSS
- approximately 0% combined CPU while idle
The process count matches the configuration: 73 worker slots, with roughly three OS processes per Codex ACP worker.
The local Codex state database also contained 40 visible threads titled `[Base] You are operating inside the Buzz platform...`:
- all 40 had `has_user_event = 0`
- 17,721,356 cumulative tokens were recorded across those threads
- threads were created across repeated Buzz agent starts over three days
The token field is reported as supporting evidence of substantial session activity; actual billed usage may differ due to caching/accounting semantics.
Quitting Buzz gracefully removed all 226 processes. Reopening Buzz without starting agents produced one `buzz-desktop` process at approximately 146 MiB. This confirms the process-tree shutdown path works and this is not an orphan-process report.
## Source-level cause
At tag `v0.4.23`:
- `desktop/src-tauri/src/managed_agents/types.rs` sets `DEFAULT_AGENT_PARALLELISM` to 24.
- `desktop/src-tauri/src/managed_agents/runtime.rs` exports that value as `BUZZ_ACP_AGENTS`.
- `start_managed_agent_process` calls `spawn_agent_child(..., false, ...)`, disabling lazy-pool startup for the manual start path.
- `crates/buzz-acp/src/lib.rs` immediately calls `initialize_agent_pool(...)` when `lazy_pool` is false.
- In contrast, launch-time restore already uses `spawn_agent_child(..., true, ...)`, with a comment explaining that eager restore would create “N idle brains.”
Relevant code:
- https://github.com/block/buzz/blob/v0.4.23/desktop/src-tauri/src/managed_agents/types.rs#L729-L735
- https://github.com/block/buzz/blob/v0.4.23/desktop/src-tauri/src/managed_agents/runtime.rs#L1840-L1850
- https://github.com/block/buzz/blob/v0.4.23/desktop/src-tauri/src/managed_agents/runtime.rs#L2100-L2125
- https://github.com/block/buzz/blob/v0.4.23/desktop/src-tauri/src/managed_agents/restore.rs#L310-L335
- https://github.com/block/buzz/blob/v0.4.23/crates/buzz-acp/src/lib.rs#L1260-L1280
## Expected behavior
Starting a normally configured local agent should not eagerly allocate 24 model-adapter workers or create user-visible Codex sessions before work arrives.
## Suggested fix
1. Change the desktop default parallelism from 24 to 1.
2. Use lazy-pool startup for manual starts, matching launch-time restore.
3. Avoid creating visible Codex Recents entries for idle ACP workers, or archive/reuse them as internal sessions.
4. Make higher parallelism an explicit advanced setting with a clear resource-cost warning.
5. Add a regression test proving that manual start with default settings does not spawn the full worker pool until the first event arrives.
Even if parallelism 24 remains available for high-throughput deployments, it is unsafe as the default for a desktop installation using Codex ACP.
Contributor guide
Research direction
Start in desktop/src-tauri/src/managed_agents/types.rs and runtime.rs, then compare the manual-start path with desktop/src-tauri/src/managed_agents/restore.rs and crates/buzz-acp/src/lib.rs. Verify how the default parallelism and lazy_pool argument affect initialization. Done means default manual starts avoid eagerly creating the full pool, with a regression test covering initialization before the first event.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100