OpenMinis: an on-device Linux sandbox for mobile AI agents
OpenMinis — The AI Agent app across platforms. Fully free and open source.
At a glance
- What is it?
- OpenMinis is a GPL-3.0 Swift and Kotlin app that gives a model a real computer on your phone: an Alpine Linux shell, browser automation, device tools and skills. The interesting part is the sandbox, and the interesting constraint is how much of it you have to compile yourself.
- Who is it for?
- Adopt OpenMinis if you want an agent that can run shell commands on the phone itself and you are willing to build iSH, PRoot, FFmpeg, LAME and the Alpine rootfs from source, or to install the APK from the releases page. Do not adopt it if you need a stable API surface for your own product, if GPL-3.0 distribution terms are incompatible with how you ship, or if you expect the iOS build to be a single Xcode open.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is that hosted agents cannot touch the phone
Most mobile AI clients are chat windows with a network call behind them. They can read what you paste and write text back. They cannot install a package, run a script, read a file from a mounted vault, or write a row into Apple Health. OpenMinis exists to close that gap: it ships a sandboxed Alpine Linux environment that runs on the device, so the agent has a filesystem, a package manager and a shell rather than a text box. The README frames the product as giving models "a real computer to work with", and the concrete examples are all local: photograph a meal and write calories and macros to Apple Health, mount an Obsidian vault as a workspace and edit Markdown in place, pull a Telegram group's messages, extract bugs, deduplicate them and file them into Apple Reminders. The target user is someone who already pays for model access through their own API keys or account sign-in and wants the execution layer to live on hardware they control. The README also states the project's own thesis plainly: technical design and code are no longer where a product's advantage lies, and the agent converges through feedback from the people using it. That is a stated position, not a technical claim, and it explains why the repository reads more like a product than a library.
Alpine on the handset: iSH on iOS, PRoot on Android
The mechanism is two different user-space Linux implementations behind one product. On iOS, OpenMinis runs iSH, described in the acknowledgements as Linux usermode emulation, specifically an ARM64 fork maintained under OpenMinis/ish-arm64. On Android, it uses PRoot, a user-space chroot, via OpenMinis/proot, with talloc listed as part of that stack. Neither requires root or a jailbreak, which is the whole point: the sandbox is a process, not a kernel feature. Around that shell sit several tool surfaces exposed to the model. Device integration covers Health, Calendar, Reminders, Contacts, HomeKit, Bluetooth, Clipboard, Media and Alarms. Browser automation lets the agent interact with pages. Workspaces split work into separate contexts addressable through the minis://workspace/ scheme, which is how a mounted Obsidian vault becomes a normal workspace rather than a special case. Native offloads hand heavy or platform-specific work to native code instead of the sandbox, which matters because emulated Linux on a phone is slow and some work should not go through it. The README does not specify the boundary between sandbox work and native offloads, and docs/specs/ is where that would live. Treat that boundary as the thing to read before you trust a workflow.
Skills load in two stages, and Claude-style skills run as-is
A skill is a folder containing a SKILL.md file, optionally with scripts, references and assets. The loading model is staged: metadata stays in context so the agent can decide when a request matches, and the body plus bundled resources load only when the skill is actually used. That is a context-budget decision, and it is the right one for a mobile app where the window is small. The compatibility claim is the more consequential part. The README states that skills built for Claude, Codex, OpenClaw or Hermes Agent generally run in Minis as-is, and that skills adapted to Minis' own tools run better because they can reach the Linux shell, device integrations and native offloads directly. Read that carefully: compatibility is described as general, not guaranteed, and the performance difference is attributed to tool reach rather than to any format change. MinisSkills is the companion repository with adapted and purpose-built skills covering TTS, search, media downloads, health analysis and cloud APIs. If you already maintain a skill library for another agent, the migration cost is likely near zero for triggering and non-zero for anything that assumes a different tool schema. The README does not document that schema difference, so you would have to inspect the specs.
Building it means compiling the sandbox, not downloading it
The build is the largest practical obstacle, and the README is direct about why: because Minis ships a Linux sandbox inside the app, the native dependencies (iSH on iOS, PRoot on Android, FFmpeg, LAME) and the Alpine rootfs are built from source rather than committed as binaries. The documented sequence starts with a recursive clone, which is required rather than optional:
git clone --recurse-submodules https://github.com/OpenMinis/OpenMinis.git cd OpenMinis
For iOS, order matters and the README says so explicitly, because FFmpeg links against LAME:
./deps/build_lame.sh && ./deps/build_ffmpeg.sh ./deps/build_ish.sh && ./deps/prepare_alpine_rootfs.sh open src/ios/Minis.xcodeproj
For Android, NDK r28 or newer is required:
./deps/build_proot.sh && ./scripts/prepare_android_sandbox.sh cd src/android && ./gradlew :app:assembleDebug
BUILDING.md is referenced for per-platform toolchain requirements, build-time customization templates and a troubleshooting section for the failure modes you are most likely to hit. The repository layout confirms the split: src/ios for the Swift and SwiftUI app plus share, widget and file-provider extensions, src/android for Kotlin and Compose plus JNI native code, src/shared for assets used by both, deps for the native dependency build scripts and vendored sources, docs/specs for architecture and interface specifications, and scripts for rootfs preparation and developer tooling. If you only want to use the app, the Android path is the releases page, which the README says always carries the latest APK. On iOS, App Store releases lag and the TestFlight build is where fixes and new features land first.
Where this design costs you: emulation, review lag and a moving target
The first limitation is structural. Running Linux in user space on a phone is emulation or syscall translation, not native execution, and the README's own inclusion of a native-offload path is an acknowledgement that some work should not go through the sandbox. Any workflow that depends on sustained CPU work inside Alpine will be slower than the same workflow on a laptop, and the material gives no figures, so treat the sandbox as suitable for package installs, scripts and file manipulation rather than for compute. The second is release cadence. The README states that App Store updates wait on review and that builds are held back when stability warrants it, with TestFlight as the leading channel. If your workflow depends on a fix, the iOS channel you can install may not have it. The third is versioning. The recent releases mix an Android 1.13 and 1.12 line with a 0.22-preview, which suggests the two platforms are not versioned in lockstep. Anyone pinning to a version number should confirm which platform that number belongs to before assuming parity. The fourth is the least visible: the repository is a full application, not a library. There is no documented embedding API for calling the agent runtime from your own app, and the specs directory is where an interface would have to be found. If you wanted OpenMinis as a component, the material does not support that reading.
Compared with a server-side agent runtime
The obvious alternative shape is a server-side agent runtime, where the model calls tools that execute on a host you provision, and the phone is a thin client. The difference is not convenience, it is where the data and the execution live. A server-side runtime can run faster, keep a persistent process, and use a normal Linux distribution without emulation. It also means your Health records, Contacts, Calendar and local files have to leave the device for the agent to act on them, or you build a bridge that exposes them over the network. OpenMinis inverts that: the sandbox and the device tools are on the same machine, so the Health write and the Reminders filing happen locally, and the only thing leaving the device is what the model provider receives as part of the conversation. That trade costs you speed and it costs you the ability to run the agent when the app is not in the foreground. If your task is long-running batch work over a large corpus, the server-side shape is the better fit and OpenMinis is the wrong tool. If your task is a short, local, permissioned action triggered from a Share Sheet or a Shortcut, the on-device shape is the reason to pick it. The README's own examples sit firmly in the second category.
Licence, maintenance and what you inherit by building it
OpenMinis is GPL-3.0. If you build from source and distribute the result, the GPL terms attach to that distribution, and this article is not legal advice, so read LICENSE and THIRD_PARTY_LICENSES.md rather than a summary. The dependency licences are not uniform: iSH is GPLv3, PRoot is GPLv2, and talloc is LGPLv3 or later, and the acknowledgements note that the full inventory with versions and license terms is in THIRD_PARTY_LICENSES.md. The practical consequence is that the sandbox is the heart of the product and it is copyleft, so a proprietary fork that ships the sandbox is not a straightforward path. Maintenance cost has two components. The first is upstream: iSH and PRoot are consumed through OpenMinis forks, which means the project carries the work of tracking two upstreams plus FFmpeg, LAME and the Alpine rootfs. The second is yours: because those dependencies are built rather than vendored as binaries, a clean checkout requires the full deps sequence before Xcode or Gradle will produce anything. The commit history shows a steady release rhythm through mid-2026, so the project is active, but activity is not the same as a stable interface. Nothing in the material describes a compatibility policy for skills, workspaces or the minis:// scheme.
Who should install it, and what to check before you do
Install OpenMinis if you want a mobile agent that can run commands and touch local data without a server in the middle, and you are comfortable either sideloading the APK from the releases page or building from source. The Android path is the lower-friction one: the releases page always carries the latest APK, and the build only needs NDK r28 or newer plus the deps and gradlew steps above. The iOS path is the higher-friction one: you need the TestFlight build or a full source build with the LAME-before-FFmpeg ordering respected, and you should expect App Store releases to trail. Skip it if you need an embeddable runtime, if GPL-3.0 distribution is incompatible with your product, or if your workload is long-running compute that belongs on a server. Before committing, read docs/specs/ to find the actual boundary between sandbox execution and native offloads, since that boundary decides which of your workflows will be fast and which will not, and check THIRD_PARTY_LICENSES.md for the full dependency licence set rather than relying on the three projects named in the acknowledgements.
Editorial conclusion
Adopt OpenMinis if you want an agent that can run shell commands on the phone itself and you are willing to build iSH, PRoot, FFmpeg, LAME and the Alpine rootfs from source, or to install the APK from the releases page. Do not adopt it if you need a stable API surface for your own product, if GPL-3.0 distribution terms are incompatible with how you ship, or if you expect the iOS build to be a single Xcode open. Verify first that your toolchain meets the Android NDK r28+ requirement and that the deps scripts complete in the documented order, because FFmpeg links against LAME and the iOS path fails if you reorder them.
Community notes