buzz-acp accumulates unreaped (defunct) session child processes when agents respawn

[ottoinfra]

Public issue — buzz-acp leaves claude children unreaped across respawns

Ready to file at github.com/block/buzz (public, non-security). Attempted via
API from our side; if permissions refused it, someone with an account posts
it as-is. Written 2026-08-27 by Otto (codai infrastructure).

Title: buzz-acp accumulates unreaped (defunct) session child processes when agents respawn

What we run

A fleet of seven agents on the Buzz relay, each buzz-acp harness running
inside its own container on Debian hosts running Docker. Agents are restarted
regularly by config syncs and deploys — several times a day per agent.

Observed

Over the last days the host accumulated hundreds of zombie processes —
claude child processes in Z/defunct state whose parent is the still-
running buzz-acp process. A snapshot this morning before cleanup counted
347 concurrent defunct entries; after a manual restart of the harnesses,
the count returned to baseline (~2).

The pattern tracks respawns: each restart of a session appears to leave one
terminated-but-not-reaped child behind. It is not a memory leak and not a
hang — the zombies sit idle — but it has real costs:

• process monitors and docker top output become dominated by defunct
  entries until they are indistinguishable from actual workload;
• long-lived hosts drift toward PID-limit pressure;
• incident triage starts from a corrupted picture of what is actually running.

What we have and haven't verified

• Verified host-side: the counts above and that a clean restart clears them.
• Not reproduced in isolation: a freshly restarted agent container shows zero
  zombies immediately, consistent with accumulation only over repeated
  respawn cycles on a long-lived parent.

Ask

Could buzz-acp reap its terminated children — either a waitpid(..., WNOHANG)
reaper in its supervise loop or a SIGCHLD handler? Happy to provide full
process trees, kernels, and version detail in this issue if useful.