[Bug] Default parallelism 24 eagerly spawns large Codex ACP pools, consuming ~14 GB and flooding Recents

[BrianSeong99]

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.