DEV Community: Ramiz Raja

Twelve Cores, Seven Devices, One Disk

Ramiz Raja — Sun, 25 Oct 2026 08:41:15 +0000

This is a republish from my site; the original is at codebyramiz.com.

A release test run on one of my Android apps sat hung for 7 hours 22 minutes and used 258 ms of CPU, before it ran a single test step.

Most advice on running several Claude Code agents says give each its own git worktree. I think that is the wrong first answer.

A worktree keeps the files apart. It does nothing for the CPU, the one test phone or the disk, and my own run proves it. The run wasn't slow, it was stuck, inside the test tool's own driver install. Nobody checked on it. Several Claude Code sessions were working on the same machine, and each had its own work to watch.

That is what running multiple Claude Code agents at once actually looks like after a few months. The problems are not in the code. If you only want the checklist, it's the table at the end; the sections in between are how each row was earned.

Git worktrees solve the files, not the machine

If you search for how to run several Claude Code agents in parallel, the answer is consistent: give each session its own git worktree and branch, so two agents never edit the same file. That's right, and I do it. It's also where the guides ranking for that search stop, from Towards Data Science to kanbots.

Here's what changed for me. One agent at a time is a tool. Four agents at a time, each with its own worker processes, builds and device runs, is a small team sharing one desk. A worktree gives each of them a separate folder. They still share:

The CPU. A Gradle build, an emulator and a test run each want most of the machine.
The test devices. There's one Pixel. Two agents can't both install onto it at once.
The disk. Every build adds cache, and nothing removes it.
Time. A hung run looks exactly like a slow one unless something checks.

The hard part is that every session is behaving reasonably on its own. No single agent does anything wrong. The failure only exists when you add them up, and no session can see the others. So the guards have to live outside the sessions, at the machine level.

My setup, for scale: an Apple M3 Pro MacBook Pro (12 cores, 36 GB), a Windows PC with an Intel i9-11900H (8 cores, 32 GB) that takes Android builds, a 2014 MacBook Pro kept as a spare, seven registered test devices, and a real-device cloud for what I don't own. The agents are Claude Code sessions that plan and review, plus cheaper coding agents that do the bulk of the work. That split is covered in how I review AI-generated mobile code.

Claude Code high CPU usage: when several sessions fan out

The first thing that broke was speed, and it took a while to see why.

A session would launch background shell commands to generate files: about twelve of them, each burning 8 to 10 percent CPU. On its own, fine. But three sessions doing something similar at the same time oversubscribed the M3 Pro, and every build, test and device run on the box slowed to a crawl. Each session saw only its own twelve workers. None of them knew the machine was full.

The fix is a Claude Code PreToolUse hook. It's registered once in ~/.claude/settings.json, so it runs before every Bash call in every session:

"hooks": {
  "PreToolUse": [
    { "matcher": "Bash",
      "hooks": [ { "type": "command",
                   "command": "$HOME/.claude-shared/scripts/resource-budget-guard.sh" } ] }
  ]
}

The hook reads the tool call as JSON on stdin. If it isn't a run_in_background call, it exits at once. Otherwise it takes one ps snapshot and counts busy processes across all Claude sessions on the machine, not just its own:

# condensed from resource-budget-guard.sh
MAX=${CLAUDE_MAX_BG_WORKERS:-$(( NCPU / 2 ))}   # 6 on a 12-core Mac
FLOOR=${CLAUDE_BG_CPU_FLOOR:-3}                 # %CPU that counts as "working"
# for each process: walk up its parents until one is a `claude` process.
#   skip the hook itself, and skip MCP servers (long-lived, not fan-out)
#   if its %CPU >= FLOOR, count it against that session
[ "$COUNT" -lt "$MAX" ] && exit 0
printf '{"decision":"block","reason":%s}\n' "$(jq -Rs . <<<"$REASON")"

The block reason names which session owns the busy workers and tells the agent what to do instead: run the command in the foreground, batch the work into one loop, or wait. Foreground calls aren't checked at all, so a blocked agent can still do the work, one step at a time. For a run that genuinely needs more, a leading CLAUDE_MAX_BG_WORKERS=8 on that one command raises the limit for that call only. The hook reads the assignment from the command text itself, because a variable set in the command never reaches the hook's own environment.

The second half is cleanup. A Stop hook warns when a session still owns more than four busy processes, and a SessionEnd hook kills the busy ones it can trace back to that session (MCP servers excluded; on the Windows box it only logs them unless reaping is switched on). That matters more than it sounds. Claude Code's own issue tracker has reports like this one, of processes that pile up and outlive the work they were started for. A worker that never gets reaped costs the machine for hours.

Sharing test phones between agents: lease, don't grab

Two agents on one phone is worse than two agents on one file, because a phone has no merge step. One installs a build while the other is mid-test, and the second agent reports a failure the app doesn't have.

The worst version of this took a long misdiagnosis to find. Two Maestro runs, on two different Android phones connected to the same machine, kept dying with:

Connection refused: localhost:7001

That error looks exactly like an app hang. I blamed the number of MCP server processes first, then a concurrent iOS session. Neither was it. The real cause was an upstream Maestro bug: before version 2.6.0 it tracked sessions per platform, not per device, so the second run's driver install was silently skipped (Maestro issue #3065). The rule now is simple: Maestro 2.6.1 or later, everywhere.

The general fix is a small device farm. Every command that touches a phone goes through a wrapper that takes a lease first:

farm-with-device --alias plannedping-pixel --holder me:gate --ttl 7800 -- \
  run-with-watchdog.sh --log gate.log -- ./scripts/run-local-release-gate.sh

The phones hang off the Windows PC, and the farm there is the only lease authority. Single commands (farm-adb, farm-maestro, screenshots) forward from the Mac over SSH; a whole gate script like the one above runs on the PC itself. If the PC can't be reached, device commands fail rather than guess.

The lease is an atomic mkdir lock with a time limit, set longer than the watchdog's own cap so it can't expire mid-run. A hook blocks raw adb and maestro calls, so an agent can't skip the queue by accident. Devices carry a policy, and the policy decides who can pick them:

Device	Availability	How an agent reaches it
Pixel 4a 5G	always	by role (default pick)
Sony	always	by role (default pick)
TCL tablet, Android 16	always	by name only
POCO (MIUI)	always	by name only, for OEM-specific bugs
Samsung S26 Ultra	on-demand	by name plus an extra flag
iPhone 15, iOS 26	always	by name only, via Appium
iPhone 11, iOS 18	on-demand	by name only

Picking by role fails closed when more than one device matches, so an agent never lands on a phone by luck.

For iPhones the agent drives the device without touching the Mac's mouse at all, which is its own story: an agent driving a real iPhone.

There was a second device problem I didn't see coming. To keep a long run from being interrupted, agents set the screen to stay on while charging, then finished and walked away. Phones sat fully awake around the clock, which drains and heats a battery even on a charging cable. Now releasing a lease arms a marker. The next Stop hook that finds a marker older than five minutes turns stay-awake off on that Android device, sets the screen timeout back to 60 seconds and switches the display off. A device that's leased again in the meantime is skipped. When a session ends, it does the same for its devices straight away.

Claude Code disk space: build caches only grow

Disk is the slowest problem and the easiest to ignore. Here's one night from the cleanup log:

00:45  disk-hygiene summary: free 56G -> 56G
03:52  disk-hygiene summary: free 24G -> 24G
05:52  disk-hygiene summary: free 12G -> 12G
07:54  disk-hygiene summary: free 10G -> 7G
08:55  disk-hygiene summary: free 3G -> 3G
10:52  disk-hygiene start:   free 1G

Below 100 GB free the cleaner starts on its own, so that night it ran almost every hour, and free space kept falling anyway. A cleanup schedule doesn't stop a disk filling: the cleaner may only delete what a rebuild restores, and the warning threshold is what tells a human to look.

That restriction is deliberate, and it's what makes the job safe to run unattended. It deletes merged worktrees, merged branches and old build/, .gradle/ and DerivedData/ folders. It never touches source, .git, .env files or keystores. A worktree with commits that no remote has is never deleted; it's logged for a human to decide.

The tricky case was dirty worktrees. A coding agent that dies mid-task leaves one behind, and I'd found six of them holding 3 to 8 GB of build output each. Keeping them forever fills the disk. Deleting them loses work. So a dirty worktree idle for 72 hours is first archived, as a binary patch plus a tarball of every untracked and ignored file except regenerable build folders, both size-checked, and only then removed. The ignored files matter: a .env or a keystore is untracked by design, and a cleaner that ignores them deletes the only copy.

Normally it runs every six hours at low priority. On a good pass it frees a lot: the largest single sweep cleared 44.5 GB across 92 paths.

The honest part: for a while it freed nothing at all, while looking like it worked. The cleanup script loaded a helper that had its own variable named APPLY, set to off. So --apply silently became a dry run. The log said "DRY-RUN", deleted nothing, and the job looked healthy. The fix was renaming the variables. The lesson was to check what a cleanup job freed, not whether it ran.

Long runs: is it hung or just slow?

Back to the opening. Nothing polled that run, and when a session finally did report on it, it read the log and said "no Maestro process alive". The process was still resident. An earlier stop signal had killed the wrapper shell and left the Java process underneath untouched. And it wasn't the port 7001 bug from the last section: that machine was already on Maestro 2.6.1.

Every run expected to take more than five minutes now goes through a watchdog:

Exit code	Meaning
0	finished
125	stalled: the log stopped growing for 600 seconds
124	hit the hard cap (7,200 seconds)
143	killed by a signal

124 and 125 mean no result was produced. They are never reported as a failing test.

A ten-minute stall check plus one thread dump named that cause immediately. Before it kills a stalled run, the watchdog takes a thread dump of the run's Java processes (jstack) and a sample of the rest of its process tree, then kills the whole tree, not just the wrapper. The dump settles the argument you'd otherwise have: if the blocking frame is inside the test tool, it's the tool; if it's inside the app's code, it's a possible product bug worth a closer look. No dump, no verdict either way.

Two rules came straight out of that run. Answer "is it still running?" from the process table, never from a log file. And kill the tree, not the wrapper.

Moving Android builds to a second machine

Once the guards were in, the Mac was still the bottleneck, because it does everything. So Android builds moved to the Windows PC. A win-build <project> <tasks> command streams the tracked files over SSH, runs Gradle on a warm cache there, and pulls the APKs back. All 13 Android repos build there.

iOS stays on the Mac, since it has to. The 2014 MacBook Pro is deliberately not a build worker. It's several times slower than the M3, and putting anything on it that someone waits for just moves the bottleneck somewhere worse.

Two machines bring a new problem: the hooks and scripts above have to be identical on both. A sync job runs every five minutes on each host through a private git repo. Before pushing, it scans local edits for secret patterns. Incoming changes are checked for shell syntax, JSON and file size before they go live, then swapped in one file at a time with an atomic rename. If an incoming check fails, the live files stay as they were and every new session on that host sees a drift warning until it's fixed. The same thinking applies to the code itself, in keeping agent-written code clean: a rule only holds if something fails when it breaks.

What to set up first

If you're running more than two Claude Code sessions on one machine, this is the order I'd do it in, by how much each one cost me before it existed:

Problem	What breaks	Guard
Runs that hang	hours lost, false "still running"	watchdog: stall at 600 s log silence, thread dump, kill the tree
CPU fan-out	every build slows, nobody knows why	block new background launches once half the cores' worth of workers are busy
Shared phones	false failures, a phone taken mid-test	leases with a time limit; raw `adb` blocked
Leaked processes	slow machine hours later	reap busy processes at session end
Disk	builds fail at 100%	scheduled cleanup of regenerable files only; archive before delete
Two machines	a fix on one host, not the other	validated 5-minute sync with a drift warning

None of this is about the model. It's the same work a team does when several people share one build server, done for agents that can't see each other. If you've inherited an app whose build and test setup already looks like this, that is the kind of thing I sort out in an app rescue.

Originally published at codebyramiz.com.

Don't Trust an Agent That Says the Tests Passed

Ramiz Raja — Thu, 22 Oct 2026 07:47:06 +0000

This is a republish from my site; the original, with the full reviewer files, is at codebyramiz.com.

You have an AI coding agent's report in front of you, and it says the tests pass. What can you conclude from that? Less than it feels like. Here is a case from my own ChatPing iOS app.

A change came back with 768 passing tests reported. I sent it to an independent reviewer. The reviewer did not rerun those tests, and its verdict begins VERDICT: FAIL, with the first two findings rated High:

[...] concurrent opens can mix chat identity and transcript. [...] If opens for A and B interleave, A can bind the ChatCapability to A while copying B's SDK snapshot into rawConversation. [...] The new tests cover only one sequential open.

[...] reopening a failed reply changes recency and rewrites the file. [...] The test fixture contains only a completed reply.

The report said 768 passed. The reviewer found two cases those tests did not cover. A green count says how many checks ran, not whether they were the right ones. The fix took two more review rounds before the same reviewer passed it.

This piece is about the three checks I put between an AI coding agent and the word "done", with the real files and verdicts. It's the same setup as how I review AI changes in a production mobile app, seen from the angle of what counts as proof.

Why an agent that says the tests pass is only making a claim

The agent that wrote the code also chose which tests to write, ran them, read the output and summarised it for me. Every step of that chain is the same author. If it misses a case when writing the code, it will often miss the same case when writing the test, and then report green in good faith.

Agents also get asked what is happening right now. "Is the gate still running?" is a claim about a process, and a model can answer it from whatever text is in front of it instead of from the process table. The seven-hour hung test run at the start of running several Claude Code agents on one machine was a version of that: a log said one thing, the machine said another.

So a report from an agent is a claim, and a claim gets checked by something that did not make it. What does that check look like when the claim is about code, about status and about a run that went quiet? Three versions follow.

A reviewer that refuses to pass tests it could not run

The reviewer in these examples is Codex, run read-only through a wrapper that demands a last line of exactly VERDICT: PASS or VERDICT: FAIL. A different worker writes the code; the worker is never the gate.

The case I find most useful is not a catch. It is a module in my shared ping-ai-sdk kit, a port of a grounding renderer from Android to iOS. The review request asked the reviewer to build and run the tests itself, so there would be pass counts that did not come from the author. It read the diff and compared it with the Android version, and it found no blocking issues in static review. It could have written "looks right, probably passes". It couldn't run the tests, so there were no independent counts, and it failed the module on that alone:

No blocking code/file:line issues found in static review. [...]

Gate blocker: I attempted all requested SwiftPM commands from `ios/`, but this
session's read-only sandbox prevented Swift/Xcode from creating `/tmp/xcrun_db-*`
cache files, so no independent pass counts were produced:
- `swift build` failed before compilation: `errno=Operation not permitted`
- `swift test --filter GroundingRendererTests` failed same way
- `swift test --filter TextFeaturesTests` failed same way
- `swift test` failed same way

VERDICT: FAIL

Does the agent's "still running" claim have a fresh check behind it?

The second check is about status, not code. When an agent tells me a build or a device run is "still in progress", I want that to rest on something it just looked up.

A CLAUDE.md rule asking for that did not hold, so it became a Claude Code Stop hook, verify-before-status-claim-hook.sh. It runs when the agent tries to end its turn and reads the transcript for that turn. If the assistant text matches a status-claim pattern and the turn contains no qualifying check, it blocks the stop. This is the pattern, abridged and not runnable as shown:

# abridged: [...] marks removed alternatives
claim_re='waiting for|still waiting|in progress|currently (mid|waiting|[...])|
should (complete|finish|fire|be done)|probably (done|finished|complete)|[...]|
still (running|underway|executing|active|going|working)|[...]|
(job|task|process|work|fork|subagent|it) (is|remains) (active|running|[...])'

A qualifying check is a Read of an image file, or a Bash command whose leading token is ps, adb, stat, date, logcat and a few more. When the hook applies, the agent gets this back and the turn does not end:

BLOCKED: this reply states or implies async/background work is "in progress" / "still
running" / "waiting" [...] but this turn contains no fresh verification [...] If you
already believe it's true from memory or a prior turn, that is exactly the failure mode
this hook exists to catch [...]

The second guard is the part people don't expect. Even when the claim is backed by a real ps, the hook blocks unless the turn also schedules the next check. One verified look is a snapshot, not monitoring. So the agent has to book a wake-up within 15 minutes, and the wake-up has to name something concrete to inspect, such as a process, a device or a log's modification time. "Check back later" doesn't count.

I should be plain about what this is: a heuristic. It checks that the current turn contains a qualifying tool call, and a bare date counts. It does not check that the call was about the task being claimed. It also stands down in some cases: when the turn itself just started background work (the wake-up guard below covers that turn instead), when jq or the transcript is missing, when the hook is already re-running after a block, and in headless worker sessions that have no next turn. It narrows the gap between "still running" and a fresh ps; it does not close it.

The script itself isn't published; it is Bash plus jq, reads the turn from the transcript path Claude Code passes on stdin, and the wake-up guard looks for a ScheduleWakeup tool call in the turn. It is registered as a Stop hook in Claude Code's settings.json:

"hooks": {
  "Stop": [
    { "hooks": [ { "type": "command",
                   "command": "$HOME/.claude-shared/scripts/verify-before-status-claim-hook.sh" } ] }
  ]
}

Seven review rounds on one hook

I did not write that hook correctly the first time. The file's own header is the changelog, and it reads like a list of ways to be wrong:

Version	What the reviewer found
v2	`tool_result` entries were logged as user turns, so the turn boundary was wrong and evidence was discarded
v3	the word `date` anywhere in a command, even `printf date`, counted as a live check
v4	a wake-up prompt of "check back later" passed with no concrete target
v5	one evidenced "still running" and then silence: monitoring ended after a single recheck
v6	a wake-up whose tool call had errored was still counted as scheduled
v7	"The background process is running" matched none of the claim phrases
v8	the phrase list kept missing wordings, so it became a subject-plus-state pattern

Those were Codex adversarial re-reviews: seven rounds against the same hook on one day. Every finding was real. My CLAUDE.md says a reviewer's finding is evidence, not an assignment, and that after two rounds on one target a third needs a written decision: fix it, register it as a follow-up, or delete the check. I didn't stop at two, and I'm not going to claim the later rounds were each priced. Whether rounds three to seven were worth it, I can't tell you. Round 7 in particular was another version of the same problem one level up, which is the pattern that rule warns about.

The later versions, v9 and v10, were not about correctness. Before v9 the hook re-read the whole transcript on every turn, which on a 71,525-line session cost about 9.5 minutes per turn. After v10 pulled the tool-call fields out in a single jq pass, a 200-call turn took 94 ms where it had taken 3.5 s. A check that takes minutes gets turned off.

Exit codes that separate "failed" from "no result"

The third check is for long runs. A release gate, a device suite or a build can go quiet. If a hung run gets reported as a failing test, I go hunting for a product bug that doesn't exist, and if it reads as "nothing wrong yet", I wait.

Every run expected to take more than a few minutes goes through a watchdog wrapper, and its exit codes carry the distinction:

Exit code	Meaning
0	the command succeeded
125	stalled: no output for the stall window; diagnostics attempted, process tree killed
124	hard cap exceeded; diagnostics attempted, process tree killed
143	the watchdog itself was signalled (TERM, INT or HUP); it killed the tree and exited
2	usage error
other	the command's own exit code, passed through

The line in long-run-watchdog.md that matters is this one: 124 and 125 are not product verdicts. They mean the run produced no verdict. One catch: a child process that exits 124 or 125 on its own looks identical from outside, so the watchdog prints a stderr line saying which one it was. A stalled run is classified from its diagnostics first, and only then is it a test failure, a tool bug or nothing.

The review gate follows the same logic. Exit 0 means a verdict exists, and I read the final verdict line (VERDICT: PASS or VERDICT: FAIL) and the opening banner, which says whether Codex or the Opus substitute produced it. A timeout is "inconclusive, not a pass", and so is any other non-zero exit. When Codex is out of quota, the wrapper falls back to a Claude Opus adversarial review, and that fallback has to produce a verdict too. No verdict never rounds up to approval.

What to copy from this setup

Make "done" a line a machine can parse (VERDICT: PASS), produced by something that did not write the code, and treat a missing line as a fail.
Make the reviewer run the tests itself, and let it fail the work when it can't.
Keep exit codes honest. "I don't know" and "it failed" must not share a number.
If you write a Stop hook for status claims, budget your review rounds before you start. Mine got seven in a day.

None of this makes the code correct. A reviewer can be wrong, and a regex can be fooled. What it does is move the question from "do I believe the agent" to "what did a second party see", and that one I can answer without reading the diff. For how the code itself stays clean when nobody reads it, see what keeps agent-written code clean.

Originally published at codebyramiz.com.