[Bug]: Concurrent agent test runs exhaust memory and crash macOS; agent memory limits are Linux-only

[rgxdev]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On a Mac, run several threads at once whose agents each run a test suite (for example vitest, which starts a worker per core in every worktree).
2. Let the runs overlap.

Expected behavior

T3 Code keeps the agents' combined memory below what the machine can take, as it does on Linux, where agents run in the systemd agents slice with MemoryHigh/MemoryMax and OOMPolicy=stop (apps/server/src/process/agentScope.ts). At worst one command fails and the machine stays responsive.

Actual behavior

Memory pressure keeps climbing. On a 32 GB Mac, memory in use reached about 100 GB (compressed plus swap), pressure stayed critical, and the system crashed, even though every session itself finished. There is no memory limit on macOS: agentScope.ts returns AgentScope.defaultValue() on every platform other than Linux, so nothing caps or reacts to agent commands' memory there.

Impact

Blocks work completely

Version or commit

T3 Code (Nightly) 0.1.1-nightly.20261016.3203

Environment

macOS 27.0.1, Apple M1 Max, 32 GB RAM, desktop app

Workaround

Run fewer test-heavy threads at once.

[peteragurto]

Concurrent agents also exhausted my memory on my fedora notebook

[rgxdev]

Additional data point: during the crash, Activity Monitor showed T3 Code (Nightly) at about 130 GB on this 32 GB Mac. Activity Monitor counts child processes toward their app, so the memory was inside T3 Code's process tree: agents and the commands they ran, not other apps. Proposed fix: #20330, an opt-in, macOS-only memory guard.

[josephv123]

Note

Claude Opus 5.5 in Claude Code, writing on behalf of @josephv123.

Another data point from a controlled run on 2026-10-18, on a smaller Mac: M5, 16 GB, T3 Code (Nightly) 0.1.1-nightly.20261018.3315, with the user's usual apps open (about 11 GB in use before any agent started).

Each agent was a real T3 thread (Claude Haiku 5.5) in its own worktree of this repo. Each one wrote and ran two vitest files, typechecked packages/shared and apps/server (the tsc-rs step peaks at about 3–4 GB), and opened one page with agent-browser.

agents at once	finished	median per agent
1	1/1	0.8 min
4	4/4	1.1 min
8	8/8	3.2 min
12	0/12 within 27 min	none finished

At 12:

• kern.memorystatus_vm_pressure_level stayed at 4 (critical), swap reached 28 GB and the load average reached 208.
• The embedded server's event loop stalled for up to 420 s, and SSH stopped answering.
• The desktop app's main process hung and had to be force-quit. It also blocked logout, because quitting has no deadline ([Bug]: A hung desktop main process leaves no record and blocks macOS logout until force-quit #21301).

The machine recovered within a minute once the agents' processes were killed.

The same workload on Linux gets through more agents but hits a different wall: the agents slice's MemoryHigh throttle stalls all agents without killing any. I posted measurements from both platforms, and a question about which direction maintainers would accept (#20330 was closed for needing that agreement first), in #21288.