Synced from GitHub
Concurrent agents also exhausted my memory on my fedora notebook
[Bug]: Concurrent agent test runs exhaust memory and crash macOS; agent memory limits are Linux-only#20329
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
- 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). - 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.
Synced from GitHub
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.
Synced from GitHub
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_levelstayed 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 (#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.
This conversation has been locked.