OpenMinis Is the Most Interesting iOS Agent Shipping, and Its GitHub Repo Has No Code In It

An indie iPhone app runs a full Alpine Linux shell on-device and bridges HealthKit, HomeKit, Photos, and Contacts into a model's tool loop. The permission prompts you'll tap were designed for a world where an app's behavior was fixed. That world just ended on your phone.

OpenMinis sat at the top of Trendshift's board this morning, described everywhere as a fully open-source cross-platform AI agent. Open the repository and you get a 37-line README, 1.19 KB, no source code. The text says the public code "is still being organized, cleaned up, and optimized for release." GitHub's own page metadata for the repo still reads "Open source coming soon." Stars sat at 315 with 13 forks and 19 open issues when I checked it this morning, which is a modest number for something ranking first on a momentum board.

So the trending open-source AI agent is currently a landing page with a star button, pointing at a closed binary on the App Store.

That would be a boring story about star inflation if the binary weren't genuinely one of the more impressive things anyone has shipped on iOS this year. It is. Federico Viticci's MacStories review walks through it in detail and he does not throw around "most impressive indie app I've seen in a while" casually. The technical design deserves the praise. The permission story underneath it deserves a much closer read than it's getting.

What's actually in there

The mechanism is clever enough that it's worth being precise about, because the precision is where the risk lives.

OpenMinis runs a version of iSH, an Alpine Linux environment emulated on-device for ARM64, sandboxed to the app's own container. Inside that shell the agent has Python, git, ssh, standard Unix text tools, and Alpine's apk package manager, which means it can pull packages off the internet at runtime. Viticci watched it install ffmpeg-class tooling and, in one test, clone and set up his own CLI project from a GitHub link, resolve dependencies, and start using it about a minute later.

Then there's the bridge layer. The developer wrote command-line wrappers around Apple's native frameworks, so the model doesn't call an SDK, it runs a command. EventKit for Calendar and Reminders. HealthKit. HomeKit. MusicKit. Photos. Vision for OCR. Apple's Natural Language framework. Speech, Location, Weather, Bluetooth, NFC, the clipboard. Web browsing via WKWebView. MCP servers reachable through code execution. Memory as markdown files sitting in a workspace exposed to the Files app as a file provider, which also means the agent can read and write any folder you've bookmarked, including ones outside its own sandbox.

Every one of those is a documented, public Apple API. There are no hacks here, no jailbreak, no private entitlements. That's the part people find delightful, and they're right to.

Here's the test that stuck with me from the review. Viticci asked how much he walked on the night he photographed a particular ship on vacation. The agent checked its own memory for the vacation dates, filtered Photos by those dates, assembled a contact sheet, picked the right image, extracted the date, called HealthKit for that day, and answered. Deterministic code, on-device, no hallucinated step.

That is a great demo. It is also a single query that touched a memory store, a photo library with location metadata, and health records, and stitched them into one answer.

The permission model is doing a job it wasn't built for

iOS consent is per-app, per-framework, and mostly one-time. You grant Photos access to an app, and what you're really doing is trusting a specific piece of compiled code that Apple reviewed and that behaves the same way tomorrow as it did today. The prompt is a decision about a program.

An agent breaks that assumption in a way the prompt has no vocabulary for. The program is not fixed. Its behavior each session is composed at runtime by a frontier model, from your prompt, from its own memory files, from tool output, and from any web page it pulls through the browser. So the grant no longer means "this app may read Photos." It means "any instruction that reaches this model may cause a read of Photos, and the result may end up anywhere the model can write."

Now stack that against the shell. The same process holds an interpreter, a package manager with network access, and outbound HTTP. Prompt injection stops being an academic concern the moment untrusted text and capable tools share a context. Viticci's own workflow has the agent scraping a web article and processing it. That's the exact adjacency: attacker-controlled text arriving in a loop that can also call HealthKit and write to a folder you bookmarked in Files.

I want to be careful here, because I am describing a structural mismatch and not a demonstrated exploit. Nobody has published an OpenMinis compromise. iOS's app sandbox is real containment, iSH runs inside it, secrets live in Keychain via native prompts, and the developer claims no data collection and no third-party analytics. The blast radius is bounded by the app container plus whatever grants and folder bookmarks you handed over.

That last clause is the whole game. The container bounds it. Your taps size it.

And the thing that makes this repo worth writing about rather than just admiring: you cannot audit any of it. The source is not published. The claim "fully free and open source" is doing work in the marketing that the repository does not currently support, and for an app requesting HealthKit and Contacts, the gap between those two facts is the most important number in the project.

Put this into practice

If you want to run this, and I understand why you would, run it deliberately.

Start with an empty agent. Install it, connect a model, and grant nothing. Deny every framework prompt on first pass. Then add exactly one capability for a task you actually have. Calendar for scheduling. Files for a single project folder. Watch how it behaves with that before you widen.

Never bookmark a root. The Files integration lets the agent read and write any folder you've bookmarked. Bookmark one working directory. Not iCloud Drive's top level, not your Documents root. The reason people get burned by this class of tool is convenience creep in the mount list, and the mount list is in settings where nobody looks again.

Treat the sensitive four as a separate decision. HealthKit, Photos, Contacts, and Location are the grants you cannot claw back meaningfully once data has flowed through a model's context and into a memory file. Ask what task justifies each one, and whether a screenshot pasted into the chat would have done the job instead.

Keep web fetching away from privileged sessions. If you're going to have it scrape and summarize pages, do that in a session that hasn't been granted health or contacts. Session hygiene is the cheapest injection mitigation available to you and it costs nothing but discipline.

Read the memory files. They're markdown in the workspace, visible in Files. Open them. This is the single best habit with any agent that persists state, because it's the only way to see what the thing decided to remember about you, and it's a two-minute read.

Watch the API bill as a tripwire. Your keys are in Keychain and the model calls are yours. An unexpected spike is your earliest signal that a session did more work than you asked for.

Honest limitations

My critique here is about a permission-model mismatch, not about anything OpenMinis is doing wrong. On the evidence available, the developer has been careful in the places that are easy to be sloppy: native permission prompts rather than blanket entitlements, Keychain rather than plaintext tokens, an emulated shell inside the app sandbox rather than anything reaching for more privilege. If I were grading intent, it would grade well.

The verification gaps are real and I'd rather name them than write around them. The repository has no code, so nothing about the app's internals can be independently confirmed; everything technical in this piece comes from the README, the project site, and Viticci's hands-on review, which is credible but is one reviewer. I found two different App Store identifiers for the app across sources, the one linked in the README and another surfaced in search, which I could not reconcile and am flagging rather than picking. The 315-star count is what GitHub served me this morning and momentum boards measure velocity rather than totals, so treat the "number one trending" framing as a ranking signal and nothing more. And "cross-platform" is doing some forward-looking work; the shipping, reviewed experience is iOS and iPadOS.

One more, aimed at my own argument. Some of what I'm describing as new risk is just the risk of running a coding agent, which plenty of us already do on laptops holding SSH keys and production credentials. The phone is arguably a smaller target than that. What's different is the data class. My laptop doesn't know my resting heart rate or where I slept last Tuesday, and the consent flow on the laptop never pretended to be a privacy guarantee in the way an iOS permission sheet does.

The thing to decide before you tap

Watch this repo, because the interesting moment is when the source lands. If the code opens and the framework bridges turn out to be as narrowly scoped as the design implies, this becomes a reference implementation for how on-device agents should work, and the star count earns itself retroactively. If it stays a landing page while the app keeps asking for HealthKit, that tells you something too.

Either way, the decision in front of you isn't whether to trust one indie developer. It's whether the permission sheet on your phone still means what you think it means when the thing behind it writes its own next step. Read the prompt, then read what you're actually agreeing to, and decide with your thumb hovering rather than after.

Sources: OpenMinis repository README (315 stars, 13 forks, 19 open issues as of July 26, 2026); openminis.app; Federico Viticci's MacStories review; iSH.