Why the bash guard got killed at 10s (2026-10-01..02)
Cause: CPU oversubscription, amplified by disk-wait pile-ups — not memory. 76 guard-bash kills across 34 sessions (10.02–23.8s). Read-only analysis; no load generated.
CPU load / core
Disk-wait procs
Kills per 1,000 Bash calls
high (≥4)
many (≥100)
6.38
high
few
3.42
low
many
0.98 (4 windows)
low
few
0.23
Details
Memory: no difference at fixed CPU (4.75 vs 4.48 busy, 0.19 vs 0.25 quiet); memory guard OK at all 76 kills; no jetsam/OOM after 09-30.
Counts reconciled: 75 / 68 / 100 are the same events with different cut-offs and keys; 794 all-hook kills are lock waits, not stalls.
Kills sit at median 5.7 load/core (p90 21.6, peak 23.4). Claude Code itself stalls too: the kill timer fires late (median ~0.9s, up to 13.8s past 10s); 5 of 14 double kills died at the same millisecond.
The earlier CPU+fork stall test (load 96 for <60s, hook timed alone) showed only ~2.4x because it reached 4–7/core briefly and did not starve the harness.
Time Machine and Spotlight ruled out. Not settled: 9 multi-session clusters (19 kills), one at only 3.2/core; and what drives the load spikes — pacer-admitted test/typecheck work ran at the same rate in busy and quiet windows, so the spikes come from unpaced work.
Follow-up proposed: sample the top CPU and disk-wait commands whenever load ≥4/core or ≥50 disk-wait, then pace what it names.