What happened
Simlock v0.4.0 is a release of an MIT-licensed tool for leasing mobile test devices to coding agents working in parallel. Its stated purpose is to give an agent a booted, checked device that no other agent can use until its lease ends or is released. The project covers iOS simulators, Android emulators, and enrolled phones. It can create devices on demand, queue requests when a machine has no capacity, and clean up idle devices. The release is available from the project’s GitHub releases page and is installed with npm i -g simlock.
The headline change in v0.4.0 is HTTP exposure for the control plane. The release notes also describe a single typed daemon contract behind every frontend, a typed daemon client using one connection, and a contract from which MCP tool schemas are derived. Rather than making each interface define its own device-management behavior, the project says it declares daemon operations once and negotiates protocol ranges. The notes further say the daemon uses one dispatcher across transports and adds roles, ownership, and an admin credential.
The version changes the lease model as well. Its release notes describe TTL-first leases on every transport and say clients renew their own leases. A lease grant returns a device projection rather than the whole record, while lease_status is scoped to the current session. The daemon is also changed so it can exit while a detached lease remains outstanding. These details matter because concurrent users of a device pool need an explicit ownership and expiry model, rather than an informal convention around shared simulator state.
v0.4.0 also expands what can be provisioned and operated. It adds on-demand installation for iOS runtimes and Android system images, plus opt-in slim iOS simulators. Simlock-owned device roots are introduced for iOS and Android. A new device.exec operation runs simctl or adb on a worker and streams the output. The release adds a gateway skeleton with configuration mode, uplink, worker views, and worker operations; subsequent changes add fleet queueing, routing, and forwarding of leases and execution requests. The notes list end-to-end tests for gateway draining, worker unavailability, reconnect rebuilding, and the gateway happy path over both the CLI and HTTP.
What the archive adds
This is a new event on a related operational thread. Herdr Packages Parallel Coding Agents as an Open Runtime described an open runtime that owns the terminals where coding agents run and makes blocked or idle work visible. Simlock addresses a different contested resource: mobile devices used by those agents.
Trend signal
The release supports Agent-ready software exposes capabilities. Simlock is making device allocation and execution available as typed, permissioned operations across CLI, MCP, and HTTP rather than leaving access to a shared simulator as an implicit local-machine practice. The evidence is implementation-level, not proof of broad adoption.
Why it matters
Parallel coding agents can multiply requests for builds, tests, and debugging, but mobile work has a physical and virtual-device constraint that ordinary source-code isolation does not solve. Two agents using the same simulator, emulator, or enrolled phone can interfere with each other even if they operate in separate worktrees. Simlock’s lease model is intended to provide exclusive allocation, queueing, expiry, and cleanup around that constraint.
The HTTP control plane broadens the possible callers beyond a local CLI or a single agent integration. A team could place device workers behind a gateway and have a scheduler, harness, or agent invoke the same operations for allocation and command execution. The practical value depends on whether the team already has enough concurrent mobile-agent work to justify operating the service.
Limits and uncertainty
The release notes establish that these capabilities were added, but they do not establish production adoption, reliability at a particular fleet size, performance, operating cost, or compatibility with every mobile-device setup. They do not provide benchmark results comparing Simlock with manual simulator management or another fleet product. Although the notes mention roles, ownership, an admin credential, and session-scoped status, they do not fully specify an organization’s authentication, network-exposure, or authorization design. Teams should evaluate the repository’s documentation and test the lease behavior in their own environment before treating it as a shared production control plane.
Skill to build now
Map the resources your coding agents can accidentally share during mobile work: simulator instances, emulator images, enrolled phones, build ports, credentials, and test accounts. Then define a minimal lease contract for one resource: request, grant, owner, expiry, renewal, release, and a visible failure state. Even teams that do not adopt Simlock can use this exercise to replace collision-prone conventions with observable allocation rules.
Reader takeaway
Simlock v0.4.0 is not another coding agent. It is infrastructure for giving several agents controlled access to the mobile devices on which their work must run. Its HTTP control plane makes that allocation layer usable by more than one local interface, while the value remains strongest for teams with real parallel mobile workloads.