ArcBox Runs Claude Code With Permission Prompts Turned Off, on Purpose

A Rust runtime for macOS boots your coding agent into a disposable microVM with its own kernel. The design is right. One sentence in the README is worth arguing with.

Most tools that promise to make AI agents safe do it by adding another question. Another approval dialog, another allowlist, another confirmation you will click through by the fourth time. ArcBox, a Rust container and VM runtime for macOS sitting at #16 on Trendshift's board this morning, went the other direction. Run abctl claude and it builds a disposable microVM, boots Claude Code inside it, attaches your terminal, and switches the agent's permission prompts off. The README states the reasoning in one clause: "because the microVM is the isolation boundary instead."

That is either reckless or the most honest thing anyone has said about agent sandboxing this year, and which one it is depends entirely on whether the boundary holds.

What the boundary actually is

ArcBox is not a wrapper around Docker Desktop. The project describes itself as written from scratch in Rust with its own VMM, VirtIO devices, filesystem sharing, and network datapath, positioned as an open-source alternative to Docker Desktop and OrbStack on macOS. One daemon and one CLI cover four tiers of workload: drop-in Docker containers with native Kubernetes, disposable microVM sandboxes, full Linux VMs, and throwaway macOS guests cloned from a base image.

The sandbox tier is the one that matters for agents. Each sandbox is a microVM with its own kernel, booted by Firecracker nested inside the guest. Nothing from your host is mounted in. /workspace starts empty, the agent clones what it needs, and you copy results back out with abctl sandbox cp. The README is explicit that this is the whole reason permission prompts come off: you are not trusting the agent to decline a dangerous action, you are giving it a machine where the dangerous action does not reach anything you care about.

The mechanics are ordinary once the primitive exists:

export ANTHROPIC_API_KEY=sk-...
abctl claude                  # first run builds the image; later runs start in ~1s
abctl claude --id review      # a second, independent session
abctl claude -- --model opus  # everything after -- goes to the agent

And the general form, for anything that is not Claude Code:

abctl sandbox create --from-image myapp:latest --memory 512 --ttl 3600
abctl sandbox run <id> -- ./untrusted-binary
abctl sandbox expose <id> 8080
abctl sandbox checkpoint <id> --name clean
abctl sandbox restore <snapshot-id>   # new sandbox, near-zero boot

The checkpoint and restore pair is the underrated piece. Snapshot a booted, idle sandbox once and every subsequent run skips the cold boot. If you are spawning agents per task rather than per session, that is the difference between a pattern you use and a pattern you talk about using.

Everything the CLI does is a gRPC call on the daemon socket with server reflection enabled, so your own tooling can create sandboxes, exec into them, move files, expose ports, and subscribe to lifecycle events without shelling out to abctl. The README also says the local sandbox is the same primitive ArcBox Platform runs in the cloud, which is a claim about a product still marked "in development," so treat the fleet story as roadmap rather than as something you can build on today.

Why the trust boundary belongs here

Every approval prompt an agent shows you is a bet that you will read it. That bet degrades. By the fortieth prompt in a long session you are pattern-matching on the shape of the dialog, not the content, and the one that mattered slides past with the rest. This is not a character flaw, it is how attention works under repetition, and it is why "the human approves each action" is a design that stops being a control somewhere around hour two.

Moving the boundary down solves a different problem than making the prompts better. A microVM with its own kernel and an empty /workspace does not need you to be alert. It does not care whether the agent was confused, jailbroken by a poisoned README, or working exactly as intended on a task you regret. The blast radius is the same either way, and it is a machine you were going to throw away.

This is the same instinct that showed up all over the week's shipping, from three unrelated organizations: Cloudflare's vulnerability service where the model "cannot apply any patch or rule it proposes," GitHub's HydraFusion critic that runs read-only in a tool-less context, Spotify's engineer discovering that routing rules in CLAUDE.md only "sort of worked" until he moved them into hooks. The lesson keeps arriving in the same shape. Put the constraint somewhere the model does not get a vote.

Put this into practice

If you are on an Apple Silicon Mac, the whole experiment is about ten minutes.

Check the hardware gate first, because it is narrow. Sandboxes need nested virtualization, which means Apple Silicon M3 or newer on macOS 15 or later, on the default VZ backend. On anything older the sandbox commands fail fast with a clear error, which is at least a courteous way to be told no. macOS guests are a separate tier and need an APFS data directory; Apple's license caps them at two per host.

Install and start the daemon.

brew install --cask arcboxlabs/tap/arcbox
abctl daemon start
abctl doctor            # sanity-check the runtime before you trust it

Try one throwaway task in a sandbox before you move any real work. Give the agent something with a clean pass/fail: clone a small repo, make a change, run its test suite, hand you back a patch. You are evaluating three things. Does the boot time hold at roughly a second on the warm path. Does abctl sandbox cp make getting artifacts out painless enough that you will actually do it. And does an agent with no permission prompts and no host filesystem feel better or worse to work with than an agent that asks.

Snapshot the good state. Once you have a sandbox with your toolchain and dependencies installed, abctl sandbox checkpoint <id> --name clean and restore from it. Rebuilding a sandbox image on every task is the friction that kills this workflow.

Drive it from your own code, not the CLI. If you are building anything that spawns agents programmatically, go straight to the gRPC surface on the daemon socket. Shelling out to abctl and parsing output is a trap you will regret about a week in.

Keep your own reviewer. The sandbox contains the damage. It does not improve the work. Whatever review step you run on agent output today still runs; the microVM just means a bad run costs you a discarded VM instead of your home directory.

Where this breaks, and the line I would push back on

The hardware requirement excludes a lot of people. M3 or newer, macOS 15 or later, Apple Silicon only, with Intel support listed as in progress and Linux host support listed under "what's next." If your team is mixed, this is not a workflow you can standardize on yet.

Public beta means public beta. v0.7.0 shipped 2026-08-15. The default branch is master, not main, which will trip your scripts. There is no single LICENSE file, only LICENSE-MIT and LICENSE-APACHE, which will trip your license scanner. Neither is a problem, both are papercuts you should know about before you find them.

The performance table needs reading carefully. The README compares cold boot, warm boot, idle memory, file I/O, and network throughput against OrbStack, and the ArcBox column is honestly headed "ArcBox target," with the table introduced as "the numbers we are working toward." That is a fair way to present aspirations. It also sits in the same visual grammar as a benchmark, and a skimmer will read five rows of ArcBox beating OrbStack and take it as measured. The genuinely measured claim is elsewhere and more modest: single-stream host-to-VM throughput of 22.7 Gbps on the custom backend, about twice Apple's VirtIO-net in the same test, with multi-flow saturation currently topping out at 10 to 12 Gbps combined. The 50-plus Gbps in the table is a goal. The 22.7 is a result.

And here is the line I would actually argue with. The README's contributing section says: "The runtime is open source under MIT/Apache-2.0. Personal use is free, and commercial use is free during the public beta." Read that twice. MIT and Apache-2.0 both grant commercial use permanently and irrevocably for the code as released. There is no mechanism by which "free during the public beta" can restrict what those licenses already gave you on the versions already published. The project can absolutely relicense future releases, and plenty of infrastructure companies have. But the sentence as written implies a limit the license does not support, and it is the kind of ambiguity that a procurement review will stop on and a solo developer will never notice.

I do not think it is a trap. I think it is marketing language that wandered into a legal paragraph. But a sandbox is the single worst dependency to be fuzzy about, because the entire proposition is "trust this boundary," and trust is exactly the currency the sentence spends. If ArcBox is planning an open-core split, the honest move is to say which parts and when. If it is not, that sentence should say "and it will stay free, because the license says so."

Where that leaves you

The design idea in ArcBox is correct and it is bigger than this one project. Agent safety built on prompts and approvals is safety that decays with your attention. Agent safety built on a kernel boundary does not care how tired you are. Watching abctl claude open a session with the permission prompts deliberately off is uncomfortable for about thirty seconds, and then the discomfort relocates to where it belonged all along: what exactly is in this VM, and what did I let it reach?

That is a much better question than "should I approve this file write."

Whether you run ArcBox specifically matters less than whether you take the move. If you have an M3 or newer, spend ten minutes and one throwaway task finding out how it feels. If you do not, ask the same question of whatever you are running now: when my agent does the wrong thing at 2am, what stops it, and is that thing something the agent can talk to?

Sources: arcboxlabs/arcbox README, read from raw.githubusercontent.com cache-busted on 2026-09-05; 2,998 stars as of the 08:12 ET check and v0.7.0 dated 2026-08-15, verified via cache-busted shields.io and ungh.cc that morning (a recheck four hours later read 2,997, which is ordinary live drift, not a correction); licenses read from the LICENSE-MIT and LICENSE-APACHE file text. Trendshift daily board read 08:12 ET on 2026-09-05, where its figures are momentum deltas rather than star totals. Comparisons drawn from Cloudflare Vulnerability Discovery and Remediation and Project HydraFusion.

Medium metadata

Title: ArcBox Runs Claude Code With Permission Prompts Turned Off, on Purpose
Subtitle: A Rust runtime for macOS boots your coding agent into a disposable microVM with its own kernel. The design is right. One sentence in the README is worth arguing with.
Tags: AI Agents, Claude Code, Rust, macOS, Developer Tools
Suggested kicker image: an ink-drawn glass box on a workbench with a small figure working furiously inside it, the workbench itself untouched and clean
Canonical: import from the fervorai.dev URL after publish