When Two Claude Agents Reach for the Same Emulator

Michael Magdy — Tue, 04 Aug 2026 10:52:53 +0000

Fixing AI agent test collisions with mic-lock

Coding agents can now test on real devices. Run a few of them at once, though, and they'll collide. Here's the small open-source tool that makes them take turns.

Claude can now handle the whole testing loop on a mobile app itself: write the code, build it, install it on an emulator or a physical device, launch it, and drive the UI to check its own work. Testing is no longer the part you have to come back and finish by hand.

And once an agent can test itself, you stop running just one at a time. You hand Claude a ticket in one Git worktree, another ticket in a second worktree, and a third in a third, and now you've got several agents working on different tasks in parallel on the same laptop. That's the fast way to work now, and it's great, right up until two of them want the same device.

Problem: Why Parallel Claude Agents Collide on Shared Emulators

Your machine can only run a couple of emulators. So picture this:

Agent A finishes its feature, installs its build on emulator-5554, launches the app, and starts tapping through the flow to verify it.

Mid-test, Agent B, heads-down on a completely different ticket, installs its own build onto that same emulator and starts driving the UI too.

Now Agent A is stuck in a hall of mirrors. Its changes have vanished from the running app, so it starts chasing a regression that doesn't exist. The screen jumps and taps fire that it never issued (that's Agent B's automation), so it starts investigating phantom navigation and "flaky" behavior.

Both test runs are corrupted, and neither agent actually did anything wrong. They just can't see each other, and nothing on the machine is telling them to wait their turn.

You find out about all of this when you sit down to review two confused transcripts and a pile of wasted tokens.

The Fix Is a Lock

This is an old, solved problem wearing a new costume: two things want one shared resource, so you put a lock on it. Mic-lock turns each device into a lock that an agent has to hold before it installs anything or runs a test.

If the device is free, the agent takes it and gets to work.
If it's busy, the agent doesn't clobber anything. It joins a fair, first-come queue and gets handed the device the moment it frees up.

A bit of what's happening underneath, because it's what makes it worth trusting:

Two layers. A tiny gate, held for microseconds, serializes every decision so two agents can never both "win" a free device. The actual hold on the device is a lease with a heartbeat.
Crash-safe. Since the lease is heartbeated, an agent that dies mid-test doesn't wedge the emulator forever. Its hold simply expires, and the next agent in line reclaims the device.
No zombies. Every hold carries a fencing token, so an agent that was slow or got bumped can't come back later and release or stomp on a device that's already moved on to someone else.
No infrastructure. It's all atomic filesystem operations under ~/.mic-lock. No server, no daemon, no Redis. It works on a plane.

None of that is theoretical. The core safety property, never more holders than the device has slots and no silent double-install, holds up structurally, and the stress tests back it up: ten contending processes, a killed holder getting reclaimed, capacity never exceeded.

You Set It Up Once; The Agents Do the Rest

The point is that nobody runs these commands by hand. You run a single command once:

mic-lock setup            # this machine  

# or: mic-lock setup --project   # committed to the repo, travels with it

That installs three things into your Claude setup:

A skill that teaches agents to take a device once and hold it for the whole task, then release it.
A guard hook that blocks any device command an agent tries to run without holding the lock and tells it exactly how to fix that. This part is deterministic, so it doesn't depend on the model remembering to be polite.
A naming rule so every agent locks the same device by the same ID.

After that, your agents coordinate themselves. Under the hood, they're just running:

mic-lock acquire emulator-5554 --owner "checkout smoke" --wait   # waits its turn  

# …install, launch, test…  

mic-lock release emulator-5554

Or wrapping a one-off command so it auto-releases even if it crashes:

mic-lock with emulator-5554 -- <build-install-test command\>

And when you're curious what the swarm is up to, mic-lock status shows who holds what and who's waiting in line. One glance instead of reading three separate transcripts.

Try It

npm install -g mic-lock  

mic-lock setup  

# restart your Claude sessions, then let your agents loose

Needs Node 18+. Android discovery uses adb; iOS uses xcrun simctl, and the lock itself needs neither. MIT-licensed and open source.

GitHub: github.com/Michael23Magdy/mic-lock · npm: mic-lock

If you've started running Claude agents in parallel on one machine, this is the piece that keeps them from clobbering each other's device. Set it up once and forget it's there.

DEV Community: Blink22 LLC

When Two Claude Agents Reach for the Same Emulator

Problem: Why Parallel Claude Agents Collide on Shared Emulators

The Fix Is a Lock

You Set It Up Once; The Agents Do the Rest

Try It