Getting Agentic Harnesses Out of the Terminal

I love agentic coding harnesses, but they shouldn’t be primarily terminal-based. The terminal is great for quick and precise commands, but information density is extremely low and UI affordances are minimal. Maybe provision of TUIs is worthwhile for occasional use (when establishing a tunnel is too annoying, or something), but it feels very strange for this to be the default modality. It took a long time for dynamic language REPLs to break out of the terminal (Jupyter notebooks and similar); I hope we don’t have to wait as long for the harnesses.

— Patrick Collison, co-founder of Stripe

Collison isn’t alone in this. At some point you stop wanting an AI client that just talks and start wanting one that does real work: writes and runs code, installs a package, builds a project, produces a PDF. The default answer has been to reach for a terminal and an existing harness like Claude Code or OpenClaw. That works well if you’re already comfortable living in a shell. It gets a lot less comfortable if you’re used to a normal app with a UI, like ChatGPT, and have never typed npm install in your life.

More people are asking for the UI version of that terminal workflow: something that gives an AI real execution capability without requiring you to become a terminal user first. Here’s how we built that in Elvean.

The building block: a real VM, not a container in the usual sense
Apple publishes containerization, a Swift package built on top of the Virtualization framework. This matters more than it sounds like it should. A normal container (Docker on Linux, for instance) shares the host kernel and isolates processes with namespaces and cgroups: real isolation, but at the OS level. Apple’s containerization package instead boots each container as its own lightweight virtual machine on Apple Silicon, with the Virtualization framework doing the hardware-level separation. Boot times stay in the sub-second range, so it behaves like a container in practice, but the isolation boundary is a real VM, not a shared kernel.

That’s the difference between “the AI probably can’t touch my machine” and “the AI is running on hardware-isolated infrastructure that literally cannot touch my machine, short of a hypervisor-level exploit.”

What we built
Every Elvean Project gets its own Alpine Linux container, running on that Virtualization-framework foundation. It’s the execution environment the model gets when it needs to run a command, install a dependency, build code, or produce an artifact. A real Linux machine, scoped to that one project, isolated from your Mac and from every other project’s container.

┌─────────────────────────────────────────────────────────────────────┐
│ macOS Host                                                          │
│                                                                     │
│  ┌──────────────────┐                 ┌──────────────────────────┐  │
│  │ Elvean           │                 │ Alpine Linux VM          │  │
│  │                  │                 │ (one per Project)        │  │
│  │ Project          │                 │                          │  │
│  │ Container Card   │ live terminal   │ Apple                    │  │
│  │  [Terminal] icon │  ◄──────►       │ Virtualization.framework │  │
│  │                  │                 │                          │  │
│  │ AI / Model       │  ───────►       │ shell, build tools,      │  │
│  │  (runs in chat)  │   commands      │ packages, network        │  │
│  └──────────────────┘                 └──────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘

Two design choices matter here beyond the isolation itself:

You can watch it work, live. Click the terminal icon on a project’s container card and you see exactly what the model is doing, in real time, as it happens: not a summary after the fact, the actual shell output. You can also type into it yourself if you want to intervene or just poke around. This is a deliberate choice: the isolation means we don’t need to hide what’s happening from you, so we don’t.

It has a shared workspace and network access, on purpose. The container mounts a workspace folder shared with your Mac, and it has network access. That’s what lets the model work autonomously (install a package, pull a dependency, write a file you’ll actually see) without stopping every few seconds to ask permission for something that, in a fully isolated VM, carries none of the risk it would if it were running directly on your machine.

Here’s what that looks like in practice: the model running Google Flights and Airbnb CLIs inside the isolated Linux container, live, to plan an actual trip.

Video

Why this is the right tradeoff
The usual agentic-AI safety story is a wall of permission prompts: approve this file write, approve this command, approve this network request. That’s a reasonable response to running an agent directly on your host machine, where every action really is a risk. It’s also exhausting, and it’s the main reason “just use a terminal harness” doesn’t work for anyone who isn’t already deep in that world.

Hardware-level isolation changes the calculus. Once the AI is running inside a real VM that can’t reach your actual filesystem or processes, most of those prompts stop being necessary. You get the autonomy that makes agentic AI actually useful, without the constant interruption, and without the exposure, because the thing the AI can affect isn’t your Mac. It’s a disposable Alpine box that exists for exactly one project.

That’s the bet we made with the sandbox: don’t ask the user to trust the model, build an environment where trusting the model isn’t the thing that has to hold.