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 those keep gigabytes of memory hostage while using no CPU at all.
Process Guard sweeps the child processes of your agents, flags the ones that stopped making progress, names the agent responsible, and ends them in one click. 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 at 4% CPU. It will never finish. Nothing will ever kill it. And if the agent that started it is closed, it gets reparented and 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. A healthy search saturates a core; these sit at 4%. 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, reparented to the init process. At that point nothing links it to anything: it is an orphan, and nobody will ever reclaim it. Two of the seven we measured were already in that state.
They pile up
One per verification pass, one per unlucky search. 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.
Watches the CPU, not just the RAM
Memory alone would flag every build on your machine. The guard measures processor usage as a rate between two scans, so a process that worked hard and then wedged is still caught, and a build that is genuinely working is left alone.
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.
The rule that keeps it from crying wolf
A guard that flags your builds is a guard you turn off in a week. So a process is never reported on its memory alone. It has to be large, it has to have been alive a while, and it has to have stopped using the processor. All three at once.
That third condition is the one that does the work. A type check or a bundler also holds gigabytes for minutes, but it saturates a core while it does. A process trapped in swap sits at around 4%, because it spends its life waiting on page faults rather than computing. That gap is what separates a machine that is working from a machine that is drowning, and it is the only signal that separates them reliably.
Processor usage is also measured rather than read. The usual figure a system tool reports is an average over the entire life of a process, which still looks busy for something that worked hard for twenty minutes and then wedged. The guard compares consumed processor time between two scans instead, so what it sees is the last minute, not the last hour.
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 only the child processes of agents that have been alive longer than your threshold and are no longer using the processor. In normal use this list is empty, and everything stops here.
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.
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. It is what keeps a slow but legitimate task from ever being flagged, since almost nothing you actually want takes five minutes while using no processor at all.
- 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, on purpose. It is the measurement that separates a working build from a stuck process, and it is not a matter of taste.
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?
No. A process is only ever flagged when it is large AND old AND has stopped using the processor. A build that is genuinely working saturates a core, so it fails the third condition and is never a candidate. That condition exists specifically to make this distinction.
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 gets reparented to the system's init process. From that moment nothing links it to the agent that started it, so nobody will ever clean it up. AgentsRoom remembers ownership while the process is still attached, which is the only moment it can be established, so it can still report the process afterwards.
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.
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.
A glimpse of AgentsRoom in action.