Coding agents are starting to carry out more and more tasks without human intervention: they modify files, download dependencies, run builds, and use the terminal. ArcBox wants to cut the risk of handing them that level of access with a different approach than constantly prompting the user. Its abctl claude command runs Claude Code inside a standalone microVM with its own kernel, filesystem, and network, without mounting the host Mac’s files by default.
ArcBox and its agent microVMs in 30 seconds
- ArcBox runs Claude Code inside a disposable microVM via
abctl claude. - The agent gets its own kernel and filesystem and starts with an empty
/workspace, with no direct access to the Mac’s files. - The sandboxes use Firecracker via nested virtualization and currently require Apple Silicon M3 or later and macOS 15 or higher.
- ArcBox also works as a Docker-compatible engine and supports Kubernetes, Linux machines, and macOS virtual machines.
- The project is written in Rust, ships under the MIT and Apache-2.0 licenses, and is still in public beta.
The project arrives at a moment when agent security is starting to look like a different problem than the one faced by traditional assistants. A chatbot that returns bad code can be caught by a developer reviewing it. An agent with terminal access can run that code, modify the repository, or install software before anyone checks each step.
“Allow this command”-style confirmations offer a barrier, but they lose effectiveness once they keep popping up nonstop. ArcBox bets on a different philosophy: let the agent work with more autonomy, but first lock it inside an environment whose reach is limited by the infrastructure itself — the same problem Cloudflare OS is trying to solve with permissions and sandboxing for enterprise AI agents.
Claude Code gets its own disposable computer
ArcBox is an open runtime for macOS, written from scratch in Rust. While its team also pitches it as an alternative to Docker Desktop and OrbStack, one of its most interesting features is aimed specifically at AI agents and running untrusted code.
The idea comes down to a single command:
abctl claude
ArcBox creates the corresponding sandbox and connects the user’s terminal to a copy of Claude Code running inside it.
The isolation goes further than simply running the agent in another directory. Each sandbox has its own kernel, filesystem, and network environment. According to the project’s documentation, nothing from the host is mounted into the microVM by default.
The /workspace directory starts out empty. If Claude needs to work on a repository, it has to clone it inside its own environment. Any files worth keeping afterward can be copied out of the sandbox and onto the host machine.
This model makes it possible to rethink a potentially dangerous operation.
If the agent accidentally deletes every file on its machine, the damage should stay contained within an environment built precisely to be thrown away. The goal is to stop that same command from ever running directly against the personal documents, repositories, and configuration stored on the Mac.
That’s why ArcBox disables Claude Code’s permission prompts in this mode. Security stops depending mainly on the user correctly approving every command and instead rests on the microVM as an isolation boundary.
Firecracker finds a new use case in AI agents
To build these environments, ArcBox uses Firecracker, though its architecture on macOS requires an extra step.
The sandboxes run as Firecracker microVMs via nested virtualization inside the guest managed by ArcBox. Firecracker was originally developed by Amazon Web Services (AWS) and is best known for its use in services such as AWS Lambda and AWS Fargate.
Its philosophy fits agents well: deliver isolation through virtualization without necessarily carrying the operational overhead traditionally associated with a full virtual machine.
ArcBox lets you create sandboxes from templates, existing Docker images, or Dockerfiles. It also supports checkpoints, so you can capture a ready-made environment and restore it later.
That opens up possibilities beyond Claude Code.
A team could prepare an image with specific compilers and dependencies, hand it to an agent, let it run a task, and tear down the environment once it’s done. A separate sandbox could handle reviewing external code without directly sharing the host machine’s filesystem.
The approach can also be useful for continuous integration (CI), automated analysis, and testing software whose provenance isn’t fully controlled.
There is a notable limitation: the sandboxes currently require a Mac with Apple Silicon M3 or later and macOS 15 or higher. ArcBox needs nested virtualization for this feature, so earlier models can’t use abctl claude the same way.
ArcBox wants to be more than a Claude sandbox
The project’s scope is considerably broader. Its goal is to keep different kinds of workloads under a single daemon and a single command-line interface.
ArcBox currently offers four main categories: containers, sandboxes, Linux machines, and macOS virtual machines.
The first works as a Docker-compatible engine. It exposes a compatible socket and lets you keep using familiar tools like the Docker CLI, Compose, BuildKit, and Buildx.
It also integrates Kubernetes through a local cluster based on k3s, and provides a kubectl connection.
On Apple Silicon machines, it supports Linux ARM64 images as well as linux/amd64. For the latter, it uses FEX as its x86-64 translation layer inside the guest.
For workloads that need a full operating system, there’s abctl machine. ArcBox can create Linux machines with their own kernel and persistent storage, with documented support currently for Ubuntu and Alpine.
The project even extends to disposable macOS virtual machines. Here it uses Virtualization.framework, Apple’s own virtualization technology, and can create copy-on-write clones of a base image.
The result is a tool that tries to bring together features that would normally be split across a container runtime, a virtual machine manager, and a dedicated platform for running agents — the same trade-off we broke down in virtualization vs. containerization.
Isolation could become a standard part of AI agents
ArcBox’s technical interest lies precisely in that convergence.
During generative AI’s first phase, the model received a question and returned text. The application could check that answer before it had any consequences for other systems.
Agents change that relationship.
A coding tool can now use Git, install packages, run scripts, launch containers, connect to the internet, and modify hundreds of files during a single task. The more autonomy it gets, the harder it becomes to rely on manual confirmation as the only safeguard.
That’s why technologies already familiar from cloud computing and cybersecurity are gaining importance here: ephemeral machines, isolation, disposable filesystems, network restrictions, and short-lived credentials.
That doesn’t mean running an agent inside a microVM removes every risk, either.
If an API key is placed inside the sandbox, the agent will be able to use it within the permissions tied to that credential. If it has internet access, it can also reach external services. And any virtualization layer can contain vulnerabilities of its own.
Isolation narrows the potential blast radius of certain mistakes, but it’s still necessary to carefully decide which resources are handed to the agent.
ArcBox stands out because it brings this principle directly to the developer’s own computer and folds it into a simple workflow. Users can give Claude Code an environment to experiment in, break things, and start over, without necessarily granting it direct access to the whole Mac.
As agents keep evolving, this model may stop being the exception. If AI tools are going to run more and more code on their own, the machine they run on could end up being just as important for security as the permissions granted to the model itself.
Frequently asked questions
What is ArcBox?
ArcBox is an open runtime written in Rust for macOS. It brings together Docker-compatible container execution, Kubernetes, agent sandboxes, and Linux and macOS virtual machines.
What does abctl claude do?
The command creates a sandbox and runs Claude Code inside an isolated microVM. The environment has its own kernel and filesystem and starts without mounting the host Mac’s files.
Can ArcBox be used as an alternative to Docker Desktop?
ArcBox positions itself as an open alternative to Docker Desktop and OrbStack, and offers compatibility with the Docker CLI, Compose, BuildKit, and other tools. The project is still in public beta, so its development status should be kept in mind.
What are the requirements for ArcBox to run Claude Code in a microVM?
The sandboxes currently require Apple Silicon M3 or later and macOS 15 or higher, due to their use of nested virtualization.
