mobile-harness
mobile-harness.com- Category
- Developer Tools
- Rank
- No. 3233Tools index
Previous survey · No. 3108 ·
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Workflow Automation
- Interfaces
- Agent Skill / Plugin
- Builder
- @nielsmdt99
- GitHub
- 439 stars
- Date
About
An open-source, markdown-based operating harness that gives AI agents (Claude Code, Codex, etc.) a consistent way to inspect, control, and recover real Android and iOS devices through a single Mobilerun API, scaling from one local phone to a cloud fleet.
What it does
A folder of written instructions that teaches a coding assistant how to drive a phone. It holds no automation engine of its own: every tap, swipe, screenshot and app launch goes through one Python library published by the same team. The text tells the assistant which guide to open for the platform at hand, when to consult per-app notes, when to switch to recovery steps, and when to stop and ask a person. Connection options cover a USB-debugged Android handset, a companion app reached over HTTP on either phone family, or hosted devices.
Why it's ranked here
The discipline is written down rather than implied. Each action is followed by a fresh look at the screen, blind action chains are forbidden, and the assistant must halt at login, payment, one-time codes or destructive consent unless the user authorised that exact step. Screen and web page text is labelled untrusted everywhere it matters, including the memory rules. For anyone pointing a model at a real handset, those guardrails are the hard part, and they ship under the MIT license with install recipes for three assistant runtimes.
What's good
Guidance is specific about failure. Tapping a hidden element raises a distinct error, scroll-until-found stops early when the view stops moving, and the Android guide explains how to tell its companion server apart from an iOS server that answers the same ping on the same port. A four-row table maps whether debugging access and the companion app are available to the correct connection mode, including the blocked case. Personal notes, credentials and per-app overrides live in one git-ignored folder, so updates never collide with user content.
Tradeoffs
The value depends on a separate library whose code is not in this repository, so the behaviour described here cannot be verified from these files alone. That library requires Python 3.11 to 3.13. Running JavaScript inside the phone browser works only on hosted devices. Local iPhone control accepts just one companion server type, and without debugging access the Android companion cannot be installed or configured. Each session begins by pulling the latest instructions from the remote repository, which means upstream text changes reach the assistant without review.
How to use it well
Fit it where an assistant already writes Python and you want repeatable phone tasks: QA passes on a test device, settings changes, or scripted browsing on a hosted handset. Register the whole folder, not just the entry file, because the guides reference each other by relative location. Pin the library versions if you care about reproducible runs, and keep the automatic update step only if you trust upstream edits. Write your own app notes in the local folder. It does not cover test assertions, reporting, or parallel scheduling across many devices.
Technical notes+
AGENTS.md is the router: it runs git -C <harness-root> pull --ff-only and a pip upgrade of mobilerun-core[local] once per session, then loads only platforms/android/GUIDE.md or its iOS twin, the matching app card, and recovery or credential guides on failure. All control goes through from mobilerun_core import Mobilerun and m.connect(..., backend=...) with backends cloud, local-android-adb, local-android-http and local-ios-http; importing mobilerun_core_local directly is disallowed. platforms/android/GUIDE.md documents device.supports("execute_script") doing a network probe once per cloud connection and the /version probe that distinguishes iosportal( responses. core/memory/GUIDE.md defines dated, sourced, confidence-tagged memory lines. .claude-plugin/plugin.json declares MIT. install.md pins Python >=3.11,<3.14.
Observed
- License
- MIT (LICENSE file and plugin manifest)
- Form
- Markdown instruction set; device control delegated to an external Python package
- Language runtime
- Python 3.11 to 3.13 required by the control library
- Install surface
- skills CLI via npx, pip into a repo-local venv, Codex skill symlink, Claude Code user-memory import, Claude plugin manifest
- Platforms
- Android over ADB or companion HTTP, iOS over companion HTTP, hosted cloud devices
- Browser scripting
- JavaScript execution in foreground Chrome on cloud devices only
- Safety rules
- Stops on credentials, payment and destructive consent; screen text treated as untrusted
- Update model
- Agent runs git pull --ff-only on the harness once per session
Read from README.md, SKILL.md, AGENTS.md, install.md, .claude-plugin/plugin.json, platforms/android/GUIDE.md, core/memory/GUIDE.md, apps/android/com.android.chrome/CARD.md, LICENSE.
What it can do
Inspect and control real Android and iOS devices
Device commands via Mobilerun API → Device state/control actions
Recover devices using recovery playbooks
Device error state → Restored device state
Route AI agent tasks to platform-specific guides, app cards, and credential rules
Agent task request → Relevant guide or credential rule
Tags
Media

Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.