Development record
macOS ran out of application memory on a 128 GB, 16-core machine on 2026-11-01 at about 17:32, with only this person's sessions active, while several agent sessions drained, built and reviewed in parallel. The Force Quit dialog lists only GUI apps (Ghostty at 8.93 GB, falling to 937 MB afterwards), so the go test processes, race-enabled test binaries and agent sessions running inside the terminal never show. The machine's counters show about 155 GiB swapped out since it booted five days earlier, so this was not the first time it ran past its RAM. The system log needs admin rights to read, so the peak was not attributed to one process; a read shortly after, with 22 test processes live at a load of 57, found the test workload at about 4 GiB and the agent sessions at about 3.8 GiB, so the consumer is unproven.
macOS ran out of application memory on a 128 GB, 16-core machine on 2026-11-01 at about 17:32, with only this person's sessions active, while several agent sessions drained, built and reviewed in parallel. The Force Quit dialog lists only GUI apps (Ghostty at 8.93 GB, falling to 937 MB afterwards), so the go test processes, race-enabled test binaries and agent sessions running inside the terminal never show. The machine's counters show about 155 GiB swapped out since it booted five days earlier, so this was not the first time it ran past its RAM. The system log needs admin rights to read, so the peak was not attributed to one process; a read shortly after, with 22 test processes live at a load of 57, found the test workload at about 4 GiB and the agent sessions at about 3.8 GiB, so the consumer is unproven.
What abcd can say is that its load gate is blind to memory: machineload's Snapshot holds load averages, cores and the process table but no memory reading, and cmd/test-parallelism derives go test -p from cores and load alone. make preflight gates itself, and an agent's own test run is gated only when it uses the command form (abcd implement load --wait -- go test ...), which the LOAD rules teach but nothing enforces (iss-2610241130157455 settled that it be taught, not enforced); either way no gate checks free memory, as it already checks free disk. iss-2610161756384596 asks for free memory as an input to how many runs are admitted; this record is the first measured outage, and asks for the floor and the attribution that would come before that.
Grounds
- pursued: on 2026-11-01 the product thinker chose to build the load gate's memory floor as an intent and to hold its planning interview, as part of the load stream they assigned that day
Frontmatter
| id | iss-2611011737317454 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2611011737317454-macos-ran-out-of-application-memory-on-a.md
open on GitHub ↗ · commit history ↗
References1
- itd-2611012048006057abcd's load gate waits for memory as it waits for loadrelated
mentions3
- iss-2610161756384596abcd's load gate admits a fixed number of preflights, one, whatever the machine can carry. The product thinker asked on 2026-10-16 that abcd know how many concurrent preflights, race runs and sub-agents are feasible from the resources it actually has, instead of a number a person sets and re-sets by hand (the machine-wide cap moved six times in two weeks: six, eight, ten, twelve, ten, fourteen).
- iss-2610241130157455Plain go test runs that sessions start outside the load gate keep the one-minute load above the gate's limit, so the gated preflights starve: on 2026-10-24 three preflights of this account waited 18, 36 and 54 minutes at 'abcd implement load --wait' (load 26 to 76 against a limit of 20 on 10 cores) while three ungated 'go test -timeout 40m' runs of other sessions (internal/surface/cli, internal/core/identity and its neighbours) ran beside them, and the session filing this had itself run internal/core/implement/... and internal/surface/cli ungated earlier the same morning. The gate counts a running make preflight and a go test -race run as occupancy, but a plain go test only as load, so the runs that skip the gate are the ones that hold it shut for the runs that use it.
- iss-2611030450356845The build's land stage ships an intent but leaves the issues the intent names in related_issues open, so the lane's own preflight then fails issue-drift (shipped_unresolved), and the loop refuses any commit after its records commit: on run-2611030127507347 (the memory floor, 2026-11-03) the lane could only be landed outside the loop, with a hand commit resolving iss-2611011737317454.