The Shell Was Already There; the Agent Is What's New: From iSH to Open Minis

Open a fresh install of Open Minis, type uname -a, and you’ll see Linux and aarch64. It’s running an Alpine userland, and running apk add python3 gives you a working Python environment right in user space. Sitting in the tool directory alongside it are tools for Calendar, Health, Bluetooth, NFC, and a built-in browser, all waiting for a model to call them.

Open Minis launched and went open source in spring 2026. The first time you see the interface, your eyes naturally lock onto the spectacle in front of you: an un-jailbroken iPhone running a Linux command-line environment with access to more than twenty system APIs. Your first reaction is: how did someone fit a Linux virtual machine onto an iPhone, and how on earth did that get past Apple’s App Review? Dig into its source code and the history of apps like it, though, and you realize that fixating on the command-line sandbox misses the point.

It Isn’t a Virtual Machine, and the Shell Isn’t New

Poke around the low-level directories of the Open Minis open-source repository and you won’t find any hardware virtualization or a separate guest kernel booting up. Instead, it pulls in OpenMinis/ish-arm64, an ARM64 fork of the open-source iSH project, to run an Alpine Linux userland inside an ordinary iOS app process. Whenever a Linux binary makes a system call—reading or writing a file, opening a network request—a kernel compatibility layer inside the host app intercepts it on the fly and translates it into native iOS calls, while machine instructions are handed off to a threaded code interpreter called Asbestos.

On iOS, interpretation is the only option, and the performance penalty is unavoidable—a direct consequence of Apple’s platform rules. As documented in iSH’s blog post on JIT and EU regulations, iOS does not grant ordinary third-party apps access to just-in-time (JIT) compilation. Without the ability to generate machine code dynamically, the Linux environment has to fall back to an interpreter. Combined with the self-containment requirements and emulator exceptions in the Apple App Store Review Guidelines, those constraints dictate both today’s interpreted architecture and the hard ceiling on its compute performance.

Putting a command line and scripting environment on a phone is over a decade old by now. From Termux on Android in 2015, to iSH in 2017, to iSH and a-Shell mini landing on the App Store in 2020, to UTM SE passing review in 2024, and now Open Minis going open source in spring 2026, local userlands and scripting environments on phones have been evolving for more than ten years.

Lay out that timeline and it becomes obvious that command-line terminals, Python interpreters, and Linux userlands have been on phones for a long time. What changed is who’s sitting in front of that black-and-white terminal. From Termux to iSH and a-Shell, the terminal was built for a human: every command had to be tapped out character by character with your thumbs on an on-screen keyboard, staring at the output before typing the next line by hand. Open Minis takes that familiar Linux sandbox foundation and layers an agent runtime on top, handing the command-line environment, the built-in browser, and system-level APIs over to a large language model. The model decides which command to run first, how to parse the returned data, how to adjust parameters when an error comes back, and when to invoke native phone APIs. The shell underneath has been around for over a decade; what’s newly wired on top is the agent runtime that takes over control flow.

Twenty-Plus Native Tools, and the List Isn’t the Point

The Open Minis iOS sandbox architecture document shows how this native bridge sits between Linux commands and native iOS frameworks: when the agent invokes a registered command in the terminal, the bridge forwards it to the corresponding native iOS API and returns the result to the terminal in structured form. To the language model, running a local script in the sandbox and calling a system-level API feel almost identical.

Commands for Calendar, Reminders, Location, Weather, and HomeKit cover much the same ground as iOS’s built-in Shortcuts and Siri, just wrapped in a uniform command-line interface with structured output. What genuinely pushes past conventional mobile scripting is Bluetooth BLE scanning with GATT characteristic reads and writes, NFC tag and protocol interactions, a built-in browser control layer with persistent login state, and the Linux environment right next to them that can install packages via apk and spin up Python or Node on demand.

Right here you can see the core difference between a tool built for humans and an execution surface built for agents. A terminal or browser meant for a human pulls its window to the foreground and expects you to watch the screen and tap through step by step. An execution surface meant for an agent doesn’t need the browser UI sitting open in front of you; as long as the app is running, the agent can drive the embedded WKWebView programmatically. Multiple tabs can run in parallel, actions within the same tab queue up in order, and everything operates under per-tab quotas and global limits. That doesn’t mean the app can run forever in the background—iOS will still suspend it under standard system policies once it leaves the foreground. It just means a human doesn’t have to babysit the browser window while a task is running, and the agent can string local scripts, web pages, and native APIs into a single continuous execution chain.

Picture a concrete workflow: you snap a photo of an event poster or a paper bill on your phone, and the agent calls native Photos and Vision APIs to run OCR, getting back raw text full of awkward line breaks and recognition noise. It then runs a Python script in the local command line to extract the exact start and end times, location, or amount, and calls the native Calendar or Reminders API to write a structured event straight into your system schedule.

Or suppose you have a Bluetooth BLE sensor broadcasting data: the agent uses the Bluetooth tool to scan and connect to the device, reads a specific GATT characteristic, and gets back a string of hex bytes. In the very same sandbox, it runs a local script to unpack the bytes according to their endianness and convert them into physical measurements, then writes the result into system health records via HealthKit or saves it to a local CSV. On the web side, you can just as easily imagine the agent driving a logged-in built-in browser to page through a dashboard, handing the extracted data to a local script to aggregate and save to disk, and firing a system notification when it’s done.

Laying out the data flow between those steps also exposes the gap between declaring a tool and getting it to work end to end. In a round of single-device testing on my iPhone, the agent could indeed call many common APIs along with tools for Bluetooth BLE, NFC, and computer vision, but some tools failed due to server-side signing configurations or missing notification permissions, and others haven’t been tested end to end yet. Likewise, whether a Bluetooth peripheral actually connects depends on its specific GATT services and how iOS manages the connection; whether NFC can read a card depends on the card protocol, cryptographic authentication, and entitlements—having an API on paper doesn’t mean you can talk to any arbitrary peripheral, bank card, or transit card out of the box. The system APIs themselves aren’t rare. The genuinely new variable is an execution chain decided dynamically by the model at runtime that spans the command line, the built-in browser, and native iOS APIs.

You Can Hand-Roll a Loop in Shortcuts, But It Can’t Replace a Runtime

The Shortcuts User Guide covers network requests, loops, conditionals, and all kinds of App Intents, so in theory you can wire up a loop in iOS Shortcuts that calls an LLM. In practice, though, Shortcuts is still a static flowchart that a human has to design ahead of time. The moment a task gets more complex, the toolset grows, a target webpage changes, or an intermediate step fails, you have to go back and redesign the flow. Open Minis is an agent runtime that decides its next step on the fly—picking tools on its own, reading web pages, and adapting its strategy when a step fails.

The difference starts with who owns the control flow. In Shortcuts, control flow belongs to whoever drew the flowchart, and which system action runs next is hard-wired into preset conditional branches. That works fine when you’re juggling two or three fixed actions, but when twenty-plus tools can be combined freely, it becomes nearly impossible to reroute based on live feedback. Shortcuts also runs on rails: if it hits a missing permission or an API error mid-flight, it stops and throws a modal alert. An agent runtime retains prior context and intermediate state, feeds the error message back to the model, and lets it tweak parameters for another try or switch to a different tool to route around the failure.

An even sharper contrast is whether you can run arbitrary code at will and drive a browser continuously. Shortcuts on iOS has no native general-purpose shell, Python, or Node environment, so it hits a wall as soon as a task requires unpacking a sensor byte stream or cleaning up messy text with a script. And as Shortcuts’ documentation on running JavaScript on webpages explains, its web scripting action is limited to a one-shot injection into a currently open Safari page. Look at Open Minis’s browser control implementation, by contrast: the app maintains a WKWebView backed by persistent data storage and exposes roughly twenty actions—navigation, screenshots, clicking, typing, scrolling, multi-tab management—so the agent can interact with web pages across multiple steps while hopping back to the local Linux environment to crunch data in Python. Anyone can cobble together an outer loop; the real divide is what sits underneath it—whether you get a full runtime for tool dispatch, state management, error recovery, and code execution, or have to rebuild that entire layer yourself out of visual blocks.

What a Phone Adds Is Physical Presence, Not Compute

Once you pack a command line, Python, and an agent onto a phone, trying to use it like a pocket workstation for heavy compilation or batch number-crunching will hit a wall fast on real hardware. Between the overhead of interpreted execution and mobile power and thermal limits, a phone sandbox is a terrible place to compete on raw compute. What a phone has that a desktop doesn’t is physical presence—being right there in the real-world environment at the exact moment an intention forms.

Step away from your desk and the phone can reach things your desktop never could: your live location, Bluetooth BLE peripherals a few meters away, NFC tags you can read with a tap, the camera and system share sheet, a built-in browser carrying active login sessions, and system notifications visible right on the lock screen. This entire execution surface stays strictly inside the app sandbox and authorized system APIs. It cannot take over the whole phone or tap around inside other third-party apps, and clicking or filling forms in the built-in browser works by dispatching events via script rather than simulating a physical finger touch on the screen.

Once you see that boundary clearly, it’s easy to picture where it shines in the physical world. Say you’re at the dinner table and the food just arrived: you snap a quick photo for the phone agent, the vision API identifies what’s on the plate, a local script calculates the nutritional breakdown, and it writes the entry straight to your health records. Wait until you’re back at your computer that night and you’ll have forgotten half the details. Or say you’re standing at a hardware workbench or out in the field holding a Bluetooth sensor peripheral: instead of walking back to grab a laptop, you pull out your phone, have the agent scan for nearby BLE devices, connect to the target service to read a few characteristic byte sequences, and run a few lines of Python on the spot to verify the packet format.

Try to stretch those in-the-moment actions into long-running jobs or an always-on background daemon, however, and you run straight into iOS’s app lifecycle and memory management. As soon as the app moves to the background, the system can suspend it at any time; if a sandbox script or the browser spikes memory usage, iOS’s memory killer, jetsam, will terminate the process outright against dynamic, undocumented limits. Add the fact that calling a sensitive API for the first time requires a human to tap through a permission prompt, and expecting it to watch over you indefinitely in the background is a non-starter. A phone’s leverage is in the present tense: it’s already in your hand the moment an intent surfaces, ready to turn what you’re looking at, the peripherals around you, and your active login sessions into immediate action.

On-the-Spot Context and Long-Term Context: Combining Them Is the Answer

Sync all your desktop Markdown notes, personal rules, and skill docs onto your phone, try to invoke your daily workflows from there, and you’ll quickly find that things don’t hook up. Your health skill expects a desktop CLI and a local database behind it; your smart-home skill points at an always-on service on your home LAN; your engineering project skills depend on a working tree full of uncommitted changes and local credentials. Even with all the docs on the phone, you can’t pick up a task mid-stream. Looking at the structure of the public Context Infrastructure repository makes the distinction clear: syncing files is not the same as having usable context, and having usable context is not the same as seamlessly continuing a task.

That gap exists because a personal agent relies on two very different kinds of context. Long-term context covers who you are, what projects you’re working on, decisions you’ve already made, your relationships, and your standing preferences. On-the-spot context covers where you are right now, what’s in front of you, which Bluetooth or NFC devices are nearby, what you just said, and the logged-in browser sessions currently open on your phone. Open Minis excels at on-the-spot context, whereas the always-on personal agents gaining traction lately—and my own context infrastructure—are built around long-term context.

Take Meta’s Muse, for example: it runs in the cloud with its own isolated browser and memory, keeps working even when you close the mobile app, and talks to you through the Muse app or WhatsApp. Another product still in private beta, Instinct, lives inside iMessage and WhatsApp, can drive a browser, and hooks into Shopify product catalogs. Both have long-term memory and cloud compute, and both can receive information from your phone via an app or user sharing, but native phone sensors like the camera, Bluetooth BLE, NFC, and HealthKit aren’t part of their direct execution surface—and the browsers they drive live in the cloud rather than in the already-authenticated sessions on your phone. Seen through that lens, we can map the space along two axes—on-the-spot dependency and continuity dependency:

To fill in that bottom-right quadrant—high on-the-spot presence and high continuity—you can split the system into three layers by response speed and context depth. On the outside is the reflex layer, using Siri and Shortcuts for zero-latency, fixed single-step commands. In the middle is the body layer, where a mobile runtime uses the camera, Bluetooth, NFC, location, and your pocket browser to sense the immediate environment and execute local actions. At the core is the memory and planning layer, where Muse, Instinct, or a long-running agent system holds cross-project history, plans multi-step workflows, and dispatches long-running jobs.

The body layer and the memory layer talk to each other through two mechanisms: active push and on-demand pull. With active push, a small set of high-signal on-the-spot events—snapping a photo, recording a voice note, scanning a tag, making a significant location shift, or explicitly sharing something—prompts the phone to package the payload alongside its provenance and privacy scope and send it to the long-term agent. With on-demand pull, the long-term agent reaches out mid-task to ask the phone for a specific observation or action, such as photographing an equipment label, scanning an NFC tag, reading a Bluetooth characteristic, or checking a webpage; the phone prompts for confirmation, runs the action, and returns a structured result. In this setup, the phone acts as a pair of eyes and hands invoked on demand, not an open firehose spraying raw sensor data into the cloud.

With those two channels in place, you can picture four closed-loop workflows connecting the physical world to a long-term system. First, from the scene to long-term memory: you snap a photo of an event poster or book cover on the go, the phone runs OCR and field extraction on the spot, and pushes a structured summary to the long-term agent to file into your project notes. Second, from long-term memory to on-the-spot action: the long-term agent crunches your project backlog and sleep logs to find your best focus window, then calls the phone to set a lock-screen alarm, block out Calendar time, or trigger HomeKit to switch your study into focus mode the moment you get home.

Third, triggering a heavy job from the field: standing at your workbench, you use the phone to read an anomalous byte sequence from a Bluetooth sensor and snap a photo of the wiring, then send the initial unpacked payload to an always-on agent in the cloud or on your desktop, which pulls up the full codebase and historical logs for a deep investigation. Finally, closing the loop back on site once that long job produces a fix: the always-on agent generates a new verification script and asks the phone to reconnect to the Bluetooth peripheral to read the characteristics again—or open an internal dashboard using the phone’s logged-in browser session—verifying the fix right where the hardware sits.

Put those four loops onto real devices and it becomes obvious that copying a few Markdown files onto a phone is the easy part. The hard engineering lies in cross-device task handoff, permission boundaries for every on-the-spot invocation, and maintaining a single source of truth for long-term memory so the phone and the cloud don’t drift into conflicting states. The goal of combining them was never to shrink a desktop computer down to pocket size; it is to let a concrete action taken in the physical world connect cleanly back into a long-running system. Phones will inevitably expose more tools over time, but tool count stopped being the bottleneck a while ago. What’s genuinely scarce is continuity across devices and execution surfaces—the ability to tie a fleeting moment in the field back into the long arc of your work.