Your agents leave processes behind.
AgentsRoom finds them.
An AI coding agent spawns a real system process for every tool it calls. Most finish in seconds. Some never do, and a handful of them running at once is all it takes to fill a machine's memory.
Process Guard sweeps the child processes of your agents, flags the ones eating your memory, one by one or as a crowd, names the agent responsible and lets you interrupt it. Nothing gets terminated behind your back.
What the guard actually looks at: the processes one agent spawned, and which of them stopped working.
An AI coding agent is not one process. Every tool call it makes starts a real one on your machine: a search, a build, a type check, a test run, a script. Multiply that by a few agents working in parallel, over a full day, and you get hundreds of processes born and buried without you ever seeing them.
Almost all of them finish. The ones that do not are the problem. A search whose pattern makes the regex engine explode does not crash and does not slow down: it allocates, gets pushed into compressed memory, and then spends its life page-faulting while the kernel swaps gigabytes for it. It will never finish. Nothing will ever kill it. And if the agent that started it is closed, it becomes an orphan that nobody on the machine is responsible for any more.
That is why the slowdown creeps. It is not one dramatic event, it is a slow accumulation over a work day, which is exactly the shape that makes people blame the wrong thing: overheating, too many agents, a memory leak in the app. On the session we measured, the app itself was using 2.8 GB across 91 processes and the eight agent CLIs 1.6 GB between them. Neither was the problem.
Process Guard is the safety net. It watches what agents leave behind, tells you which one is stuck and who started it, and lets you end it. The root causes will keep changing, another tool, another pattern, another provider. The net does not have to.
Why a machine running AI agents gets slow
The numbers below come from one measured session on a 16 GB laptop with eight agents running. Nothing here is an estimate.
The machine had been up five and a half hours. No thermal issue at all: no throttling recorded, battery at 30.6 C. The load average was between 17 and 21 on 8 cores, and the CPU was spending 56% of its time in the kernel for 1.5% idle. That ratio is the tell. A machine doing real work spends its time in user code; a machine at 56% system time is a kernel doing nothing but compressing, decompressing and swapping memory.
Seven stuck search processes were holding between 3.9 and 8.0 GB each, 41.8 GB claimed in total on a machine with 16 GB of RAM. Swap was at 22.3 GB out of 23.5, and roughly 993 GB had been written to swap since boot. Ending those seven processes returned 15.5 GB instantly, without restarting a single agent and without restarting the app.
The reason nobody catches this by hand is that the usual tools lie about it. On macOS a stuck process can show 20 MB of resident memory while actually holding 8 GB, because everything it touched went through the memory compressor. We measured a live one at 4.7 GB of resident memory for a real footprint of 14 GB. The virtual size is no help either: on that platform even launchd reports around 440 GB of virtual size, so filtering on it flags the entire machine.
The same session, hour by hour: the slabs of memory nobody is using any more, and what happens when they are released.
And these processes have four properties that guarantee they will still be there tomorrow.
They never finish
Their own memory is in swap, so they spend their time page-faulting instead of computing. They are not sitting idle while they do it: the runaways we measured were each burning between 10 and 19% of a core, and the more of them pile up the less each one gets. There is no way out of that spiral, and no amount of waiting helps.
They never die
There is no timeout on a tool call. Nothing on the machine has an opinion about a process that has been idle for fifty minutes. It will sit there until someone kills it or the machine reboots.
They outlive their agent
Close the agent tab and the process can survive. Every system breaks the link differently: classic Unix reparents it to init, a Linux desktop to your systemd user manager, and Windows reparents nothing at all and leaves it pointing at a parent that no longer exists. So the guard never looks at parents. It remembers what it adopted while the link was still there, and treats anything missing from the live tree as an orphan, identically on the three systems. Two of the seven we measured were already in that state.
They pile up
One per verification pass, one per unlucky search, and one more every time an agent reads a slow command as a hung one and starts it again. We measured twelve type checks running at once, started by six agents, two of which had three in flight. That is why the slowdown is strictly increasing across the day and why a reboot appears to fix it. It does not fix anything, it just resets the count.
What Process Guard does
It watches the processes your agents spawn, and it is deliberately narrow about which ones it will touch.
Measures real memory
Not the resident size, which understates a stuck process by gigabytes. The guard reads the real footprint with compressed and swapped-out pages included, so a process showing 20 MB and holding 8 GB is seen for what it is.
Measures the processor, never trusts it
Processor usage is read as a rate between two scans, not as the lifetime average a system tool reports, so a process that worked hard and then wedged is still caught. What it buys is a higher bar for something still working, never a free pass: a runaway burning a fifth of a core is exactly what the first version of this guard used to miss.
Catches orphaned processes
A process that outlived the agent that started it is reported on its own merits, because nobody else will ever reclaim it. Ownership is remembered while the process is still attached, which is the only moment it can be established.
One click to end it
A chip in the status bar lists each stuck process with the agent that spawned it, its memory, its age and its CPU. Ending one terminates it and anything it forked. The memory comes back immediately and your agents keep running.
macOS, Windows and Linux
Each system needs a different measurement to tell the truth about memory: compressed pages on macOS, resident plus swapped on Linux, private commit on Windows. All three are implemented, not planned.
Costs almost nothing
One process snapshot per minute, measured at about 40 ms on a machine running 824 processes. The expensive memory probe only runs when something already looks stuck, and no scan runs at all while no agent is active.
Sees the crowd, not just the outlier
Twelve type checks at 1.4 GB each are 16.8 GB on a 16 GB machine, and every single one of them sits under a sane threshold. When the processes your agents started fill half the machine's physical memory between them, size stops being judged one at a time.
Names the agent responsible
Two or more flagged commands from the same agent are grouped under its avatar, with what they hold together and a warning explaining the loop they are caught in. One command is an accident; several at once is a behaviour.
Interrupts the agent, not just the process
Ending a process while its agent is mid-turn hands that agent an error it reacts to, often by running the command again. One button sends Ctrl+C to the agent's terminal instead: its turn ends, nothing relaunches, and the agent stays open.
The rules that keep it from crying wolf
A guard that flags your builds is a guard you turn off in a week, so the bar is deliberately high. Every child process of an agent that has been alive longer than your threshold gets its real memory measured, and it is reported once it holds more than you allowed. A process still using the processor has to hold twice that, which is what keeps a long, legitimate build out of the way.
Processor usage sets that bar; it is not a gate. The first version of this guard required a process to be idle before it would even look at its memory, and that was wrong. A search whose pattern makes the regex engine explode is not idle: it burns a fifth of a core while the kernel swaps gigabytes for it. Worse, the more of them pile up the less processor each one gets, so the blind spot was widest at the very beginning, when ending one was cheapest.
The second rule exists because a bar per process cannot see a crowd. Twelve type checks holding 1.4 GB each are individually reasonable and collectively fatal on a 16 GB machine. So when everything the agents started adds up to half the machine's physical memory, all of it is reported, whatever each piece weighs on its own. Nothing in that group is ever ended automatically: it is below the limit you set, and it was only flagged because of its neighbours.
How it works
Four steps, once a minute, and the expensive one almost never runs.
One cheap snapshot of the machine
Every minute the guard takes a single snapshot of all running processes and walks the tree below each agent terminal. Measured cost on a machine running 824 processes: about 40 ms. While no agent is running, this does not happen at all.
Shortlist the suspects
From that snapshot it keeps every child process of an agent that has been alive longer than your threshold. That is the whole filter, and nothing is excluded for still using the processor: doing that is exactly how the earlier version of this guard missed runaways. In normal use the list is empty, since an agent's tool calls finish in seconds.
Measure the ones that look stuck
Only for that shortlist does the guard pay for the real memory measurement, compressed and swapped-out pages included. A process it cannot measure is never flagged: an unknown is not a verdict.
Report, and let you decide
A chip appears in the status bar and a single notice tells you about it once. You open the list, see what the process is, how much it holds, how long it has been stuck and which agent started it, and you end it if you want to.
What it will never touch
A tool that can end processes has to be narrow about what it considers its business. These limits are structural, not options you have to remember to switch on.
- The agent CLI itself. Whatever provider you run, the guard protects the binary the app used to launch that terminal. It reads that name from the launch itself rather than from a hardcoded list, so a sub-process of the same CLI is protected too, at any depth.
- Your dev command terminals. A dev server sitting idle matches every runaway criterion: fat, old, no processor usage. It is also the one process you actually want running. Only agent terminals are watched, so your dev server is never in the picture.
- The shell and the app's own plumbing. The terminal helper and the shell an agent runs in are excluded by construction. Only the tool processes below the agent CLI are ever candidates.
- Anything it did not adopt. The one path that can end a process refuses any process the guard did not pick up from an agent's own tree. It cannot become a way to terminate something else on your machine.
And nothing is ended automatically unless you ask for it. By default the guard reports what it found and you decide, because you are the one who knows whether a large, quiet process was expected. Even switched on, automatic termination leaves alone anything still using the processor, and anything flagged only for what its neighbours hold.
When it earns its place
Every one of these is a real situation, not a hypothetical.
The machine slower at 6pm than at 9am
No single moment where it broke, just a steady slide across the day. That shape is almost always accumulated stuck processes, and it is the hardest one to diagnose by hand because nothing looks wrong at any given instant.
Several agents working in parallel
The more agents you run, the more tool calls happen, and the more chances one of them wedges. The failure rate per call is tiny; multiplied by a day of parallel work it stops being tiny.
A search that never comes back
A pattern that makes the regex engine explode allocates gigabytes on a file of a few hundred kilobytes. The agent waits on it, you wait on the agent, and the machine pays for both.
You closed the agent, the process stayed
Closing a tab does not always free anything. A process that was already detached keeps its memory and loses its last link to anything you can see in the app.
A laptop with 16 GB
On a machine with plenty of RAM a few stuck processes hide for a long time. On a 16 GB laptop they hit swap fast, and once the system starts compressing memory every single agent gets slower at the same time.
Before you blame the app
When a machine crawls while AgentsRoom is open, the app is the obvious suspect. Having the real numbers, per process, with the agent that started each one, turns a suspicion into something you can actually check.
You set the limits
The defaults are deliberately cautious. Everything below lives in Settings, under Terminal, and every one of them can also be read and changed by an agent through the AgentsRoom MCP tools.
- Watch agent child processes
- On by default. Turn it off and no scan runs at all, ever.
- Report above a memory threshold
- Two gigabytes by default. Below that, a stuck process is not worth interrupting you for. Raise it on a workstation with a lot of RAM, lower it on a laptop where memory is tight.
- After a minimum lifetime
- Five minutes by default. Below that nothing is even measured, which is what keeps an agent's ordinary tool calls, the ones that finish in seconds, out of the picture entirely.
- End stuck processes automatically
- Off by default, and that is a deliberate product decision rather than caution. The guard is making a judgement call, and only you know whether a large, quiet process was expected. Turn it on and it acts by itself, with a notification after the fact.
The processor threshold is not exposed, and neither is the point at which the machine counts as saturated. Both were wrong once and were fixed by measuring real incidents rather than by taste, so a slider on either would mostly be a way to put the blind spot back.
Frequently asked questions
Does this mean AgentsRoom slows down my computer?
No, and that is precisely why the feature exists. On the session we measured, the app was using 2.8 GB across 91 processes and the eight agent CLIs 1.6 GB between them. The 41.8 GB were held by tool processes that had wedged. AgentsRoom happens to be the only place that can see every agent and every process it spawned, so it is the only place that can arbitrate.
Will it kill my build or my test run?
It will never end one without asking. It can report one: a build has to hold twice your threshold, four gigabytes by default, or be part of a group of agent processes filling half your machine's memory. But automatic termination never touches a process that is still using the processor, nor one flagged only because of what its neighbours hold. In both cases you get a row, the real numbers and a button, and nothing happens until you press it.
Does it watch my dev server?
No, and it never will. A dev server sitting idle matches every runaway criterion: it holds a lot of memory, it has been running for hours, and it uses no processor between requests. Only the child processes of agent terminals are watched, so your dev commands are outside the scope by construction.
Can it terminate the agent itself?
No. The agent CLI is protected whatever provider you use, and the protection is based on the binary the app used to launch that terminal rather than on a list of known names. The shell and the app's own terminal helper are excluded as well.
What is an orphaned process and why does it get special treatment?
A process whose parent has exited loses the link to the agent that started it, and nobody will ever clean it up. How that link breaks depends on the system: classic Unix reparents it to init, a Linux desktop to your systemd user manager, and Windows reparents nothing and leaves a dead parent id behind. So AgentsRoom never tests parents. It records ownership while the process is still attached, which is the only moment it can be established, and treats anything missing from the live tree as an orphan, identically on all three systems.
How much does the monitoring itself cost?
One process snapshot per minute, measured at about 40 ms on a machine running 824 processes. The more expensive memory measurement only runs on processes that already look stuck, which in normal use means it does not run. And the scan does not exist at all while no agent is active.
Why not just look at the memory column in Activity Monitor?
Because on macOS it understates the problem by an order of magnitude. A process that has been pushed into compressed memory can show 20 MB resident while holding 8 GB. We measured a live one at 4.7 GB resident for a real footprint of 14 GB. The virtual size is no better: even system processes report hundreds of gigabytes of it.
Does it work with Claude Code, Codex and the others?
Yes. The guard knows nothing about any specific tool or provider. It watches the child processes of whatever agent terminal you started, and the CLI it protects is read from the launch itself. Adding a provider changes nothing here.
Does it work on Windows and Linux?
Yes. Each platform needs a different measurement for memory to be truthful: compressed pages on macOS, resident plus swapped-out on Linux, private commit on Windows. All three are implemented.
Will it end processes without asking me?
Not unless you switch that on. By default it reports what it found, with the agent, the memory, the age and the processor usage, and you decide. Automatic termination is a setting, off out of the box.
What happens to the agent when I end one of its processes?
The agent keeps running. Its tool call receives an error instead of hanging forever, which is the outcome you want: the process was never going to finish anyway. Nothing is restarted and no context is lost.
Does it fix the root cause?
No, and it does not try to. The causes change: one tool today, another pattern tomorrow, another provider next month. This is a safety net, and it is designed to keep working when the cause is one nobody has seen yet.
Twelve processes, not one of them over my threshold. Will it say anything?
Yes, and that case is why the rule changed. Measured on a 16 GB machine: twelve type checks started by six agents, 0.84 to 1.72 GB each, all comfortably under a 2 GB threshold, 15.4 GB between them, swap full and the machine unusable. Judged one at a time, every single one was fine. Once the total passes half your physical memory, they are all reported, grouped under the agent that started them.
What does Interrupt the agent actually do?
It sends Ctrl+C to that agent's terminal, the same keystroke you would press yourself. The agent's current turn ends and it waits for you: it is not closed, its session is intact, and nothing else on your machine is touched. It exists because ending a process while the agent is still working on it only treats the symptom, since the agent gets an error and frequently just runs the command again.
You may also like
Context Canary
The other early warning: it watches the agent's own context rather than the machine, and tells you when an agent is drifting before it starts inventing files and APIs.
Dev Terminals
Run your dev servers and long commands in AgentsRoom, with a notification when a long one finishes. These terminals are exactly the ones the process guard is built never to touch.
Agent Status Tracking
See at a glance which agents are working, which are waiting on you and which are idle, without reading a single terminal.
Token Usage
The other resource worth watching. Per-agent token consumption and quota, so you know where your usage is going.
Split View
Several agents side by side in one window, each with its own pane, colour and live status.
CLI Doctor
When an agent fails to start, it tells you why and what to do about it, instead of leaving a blank terminal.
Stop paying for processes nobody is using
AgentsRoom is free to download, and the process guard is on from the first launch.
Companion app: monitor your agents on the go
Bring your own: Claude, Codex, Antigravity CLI, or other AI provider.
Push bugs and requests straight to your public backlog.