OpenMinis hands the model a Linux shell and compiles its own sandbox

A sandboxed Alpine Linux is the agent's computer

OpenMinis describes itself as a private, on-device AI agent that brings Claude, GPT, Gemini and other providers into a native mobile experience. The model is not the point of the product, the computer around it is: a sandboxed Alpine Linux environment runs on the device, the agent installs packages, runs scripts and works with real files there. Alongside that sit browser automation, persistent memory across sessions, and native offloads that move heavy or platform specific work out of the sandbox into native code. Integrations with Health, Calendar, Reminders, Contacts, HomeKit, Bluetooth, Clipboard, Media and Alarms are exposed to the agent as tools rather than as settings. Models come from your own API keys or an account sign-in, which is what the bring your own model line means in practice: you choose the provider, the app supplies the environment. The project also states where it thinks the value sits, arguing that technical design and code are no longer where a product's advantage lies and that the product converges through a feedback loop with the people using it. Outside coverage has appeared at MacStories in July 2026, on Zhihu in June 2026 and on Appinn in March 2026, each treating it as an agent built for the phone rather than an assistant attached to one.

Skills load on demand from a folder holding SKILL.md

A skill is defined structurally, not by a plugin manifest: it is a folder with a SKILL.md file containing instructions and, optionally, scripts, references and assets. The loading model is split in two. Metadata stays in context so the agent can decide whether a request matches a skill, and the body plus any bundled resources load only when the skill is actually used. That is why a large library of skills does not have to sit in every request. The compatibility story is the part worth noting: OpenMinis has its own tool system but does not require skills written for it, and skills built for Claude, Codex, OpenClaw or Hermes Agent generally run in Minis as-is. Skills adapted to Minis tools run better, because an adapted skill can reach the Linux shell, the device integrations and the native offloads directly.

Workspaces are addressable as minis://workspace/ targets

Work is split into workspaces, separate contexts you can organise around, and each one is addressable through a `minis://workspace/` URL. One of the listed workflows mounts an Obsidian vault as a normal workspace, so research, cleanup and Markdown notes land back in the vault as files. Another pulls messages out of a Telegram group, extracts bugs and action items, deduplicates them and files the results into Apple Reminders.

Five native dependencies are compiled on the first build

Because the app ships a Linux sandbox inside it, the native pieces are built rather than downloaded: iSH on iOS, PRoot on Android, FFmpeg, LAME and rclone, plus the Alpine rootfs. Nothing is committed as a prebuilt binary, and the clone therefore has to bring submodules along:

git clone --recurse-submodules https://github.com/OpenMinis/OpenMinis.git
cd OpenMinis
./deps/build_lame.sh && ./deps/build_ffmpeg.sh
./deps/build_ish.sh && ./deps/prepare_alpine_rootfs.sh
./deps/build_rclone_ios.sh
open src/ios/Minis.xcodeproj
./deps/build_proot.sh && ./scripts/prepare_android_sandbox.sh
./deps/build_rclone_android.sh

The repository layout explains why the scripts live where they do:

src/ios/          iOS app (Swift / SwiftUI) + share, widget and file-provider extensions
src/android/      Android app (Kotlin / Compose) + JNI native code
src/shared/       Assets shared by both platforms
deps/             Native dependency build scripts and vendored sources
docs/specs/       Architecture and interface specifications
scripts/          Rootfs preparation and developer tooling

So a first build is a toolchain exercise, not a package install. The quick version on the page also ends with a copy into src/android/app/libs, and the full first-build guide is BUILDING.md. Once the scripts are done, what you compile is more than one binary on iOS: src/ios/ carries the SwiftUI app plus share, widget and file provider extensions, while the Android side pairs a Kotlin and Compose app with JNI native code. The interface contracts between those pieces are written down in docs/specs/, which the layout lists as architecture and interface specifications, so that directory is where you look for the boundaries between app, sandbox and offloads.

FFmpeg links against LAME, so the script order is fixed

The build scripts are not interchangeable and the page is explicit about why: order matters, because FFmpeg links against LAME, so `./deps/build_lame.sh && ./deps/build_ffmpeg.sh` is a single step with a dependency inside it rather than two things you may reorder. The toolchain differs by platform. iOS needs Go 1.25+ and Xcode's Metal Toolchain, which you fetch with `xcodebuild -downloadComponent MetalToolchain`, and the result is opened through `open src/ios/Minis.xcodeproj`. Android needs NDK r28+, Go 1.25+ and gomobile, and it goes through `./deps/build_proot.sh` plus `./scripts/prepare_android_sandbox.sh` instead of the iSH and rootfs pair. BUILDING.md is where the per platform toolchain requirements, the build time customization templates and a troubleshooting section for the failure modes you are most likely to hit actually live.

A GPL-3.0 app built on GPL and LGPL sandbox components

The license picture is layered, and the sandbox is where the obligations come from. iSH is GPLv3 and provides Linux usermode emulation on iOS, and the app runs an ARM64 fork of it rather than upstream. PRoot is GPLv2 and provides the user space chroot for the Android sandbox, again through a fork, with talloc (LGPLv3+) underneath it. Alpine Linux is the minirootfs the sandbox boots, and the media and text side adds FFmpeg (LGPL-2.1+), LAME (LGPL) and cppjieba (MIT). OpenMinis itself is GPL-3.0. The page keeps the inventory out of the README and points at THIRD_PARTY_LICENSES.md for the full list with versions and license terms, which is the file to read before you redistribute a build, since the terms of the emulated Linux environment travel with the app.

App Store review is why 0-beta-build tags move first

Recent tags are 0-beta-build40, named Android 1.16-beta.2 (build 40) and published on 2026-11-03, 0-beta-build39 for Android 1.16-beta.1 on 2026-11-01, and 0-beta-build38-diag, a PRoot seccomp diagnostic build of Android 1.16 published on 2026-10-30 and marked as not a release. Separately, App Store releases can lag behind, because every update waits on review and the project holds builds back when stability warrants it. And the tag names wrap two version schemes at once, an Android build counter sitting inside a release name that starts at zero, so a tag tells you the Android build and the beta number but not the iOS version. The TestFlight build is where fixes and new features land first, and on Android the releases page always carries the latest APK. The last push to main was on 2026-11-01.

The listed workflows all begin with a device permission

The examples the page gives are not prompt tricks, they are integration paths, and each one starts outside the app. Photograph a meal and the app identifies dishes, estimates calories and macros and writes them to Apple Health. Let a Shortcut trigger it and it fetches an X timeline, summarises it, synthesises speech and plays it as the alarm. Send a page or a message through the iOS Share Sheet and it creates the calendar event with time and place included. Each of those depends on Health, Reminders, Calendar, Shortcuts or the Share Sheet being available and permitted on the device. The OpenMinis/AwesomeMinis repository, a curated community collection of workflows across health, productivity, research, finance and developer tooling, is the place the project points for more.

Editorial conclusion

OpenMinis fits a developer who wants an agent that can install packages, run scripts and reach phone integrations through a shell it controls, and who is willing to read BUILDING.md before touching the source. It does not fit someone who needs a predictable release channel, since App Store updates wait on review and the newest fixes land on TestFlight first. Before you build or install it, read BUILDING.md for the per platform toolchain (Go 1.25+, the Xcode Metal Toolchain, NDK r28+, gomobile), check THIRD_PARTY_LICENSES.md for the GPL and LGPL terms the sandbox components carry, and confirm that the build you are installing can sign in to the model provider you plan to use.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. OpenMinis/OpenMinis on GitHub
3. Project website
4. README
5. Releases