Coding agents are becoming increasingly autonomous, but that freedom raises an uncomfortable question: what happens when an agent capable of executing commands has access to the same computer, files, and credentials as its owner? ArcBox proposes replacing permission prompts with actual isolation: abctl claude runs Claude Code inside an independent microVM with its own kernel, filesystem, and network, without mounting the host Mac’s files by default.

The key points about ArcBox and Claude Code in 20 seconds

abctl claude runs Claude Code inside a disposable microVM isolated from the Mac.
Each sandbox has its own kernel and filesystem, with /workspace starting empty.
Claude Code permission prompts are disabled inside this environment because the microVM acts as the isolation boundary.
ArcBox also supports Docker, Kubernetes, and full Linux and macOS virtual machines.
The project is written in Rust, is currently in public beta, and has more than 3,000 stars on GitHub.

The approach is particularly relevant because it tackles one of the problems emerging as tools such as Claude Code move beyond suggesting a few lines of code to executing commands, installing dependencies, modifying files, and working for extended periods with little human intervention.

Manually approving every operation can provide control, but it can also lead to permission fatigue. Once users start clicking “Allow” almost automatically, the dialog loses much of its value as a security mechanism.

ArcBox attempts to move that responsibility to a lower layer. Instead of relying primarily on a person to inspect every action, it limits what the agent can access in the first place.

`abctl claude`: Claude Code Gets a Disposable Machine

ArcBox is an open-source runtime for macOS written from scratch in Rust. Its developers describe it as an open-source alternative to Docker Desktop and OrbStack, although its capabilities extend beyond running containers.

The same daemon currently supports four main types of workloads: Docker-compatible containers, sandboxes for agents and untrusted code, full Linux machines, and disposable macOS virtual machines.

The agent sandboxing functionality is arguably the most interesting part.

Running:

abctl claude

causes ArcBox to prepare a sandbox and attach the terminal to Claude Code running inside it. According to the project’s documentation, these sandboxes are independent microVMs running through Firecracker nested inside the guest virtual machine.

It is not simply an isolated directory.

Each microVM has its own kernel and filesystem. ArcBox also states that nothing from the host computer is mounted inside the sandbox. /workspace starts empty, and the agent must clone whatever it needs itself. Results that need to be preserved can subsequently be copied back out of the machine.

That changes the risk model.

An agent that accidentally executes a destructive command may destroy its working environment, but the intention is for that environment to be a disposable machine rather than the developer’s personal filesystem.

The documentation therefore states that Claude Code runs with its permission prompts disabled: ArcBox intends the microVM, rather than each individual user confirmation, to act as the security boundary.

From Asking “Allow?” to Limiting What the Agent Can Touch

Permission prompts remain useful, but the growth of autonomous agents is making a familiar weakness of security interfaces increasingly visible: too many confirmations can become routine.

Users read the first few. They then begin to recognize common commands. Eventually, they may approve operations almost reflexively just to keep the agent working.

ArcBox takes an approach closer to one that has been used for years with untrusted workloads in cloud infrastructure: assume that a process may do something unexpected and contain the consequences through isolation.

That does not automatically make everything performed inside a VM safe. An agent can still access resources deliberately provided to it, connect to external services when networking allows it, or use credentials introduced into its environment. A virtual machine also does not eliminate hypervisor vulnerabilities or the possibility of other escape mechanisms.

It does, however, reduce an important category of risk: an agent with broad permissions directly browsing or modifying the user’s personal filesystem simply because it was allowed to execute a command.

The model is particularly suitable for disposable tasks such as reviewing a repository, running tests, compiling unknown software, analysing third-party code, or allowing an agent to try several approaches without needing to preserve the entire environment.

Firecracker Comes to the Desktop to Isolate AI Agents

The choice of Firecracker is not accidental either. The microVM virtualisation technology was originally developed by Amazon Web Services for workloads including AWS Lambda and AWS Fargate, with the aim of combining fast startup with virtual-machine-based isolation.

ArcBox applies that concept to a different scenario: local AI agents.

According to its documentation, sandboxes can be created from templates, existing Docker images, or Dockerfiles. Users can also checkpoint an already prepared machine and restore it later, reducing the time required to start another session.

There are, however, important hardware requirements. Sandboxes need nested virtualisation and currently require Apple Silicon M3 or newer and macOS 15 or later, using the default VZ backend. As a result, abctl claude cannot currently be used in the same way on every Mac.

The project is also still in public beta, something that should be considered before treating it as a direct replacement for mature tools in production environments.

ArcBox Also Wants to Compete With Docker Desktop and OrbStack

ArcBox would be considerably more limited if its only purpose were to wrap Claude Code inside a VM. Its broader goal is to provide a common runtime for several types of local workloads.

It can operate as a Docker-compatible engine by exposing a compatible socket, allowing developers to continue using Docker CLI, Compose, BuildKit, and Buildx. It can also launch a local k3s cluster and integrate it with kubectl.

On Apple Silicon, ArcBox can run both linux/arm64 and linux/amd64 images. For x86-64 workloads, it uses FEX translation inside the guest.

When a container is not enough, abctl machine can create complete Linux virtual machines with their own kernel, persistent disk, and selected distribution. The project currently documents support for Ubuntu and Alpine.

ArcBox can even create disposable macOS virtual machines using Virtualization.framework and copy-on-write clones of a base image. According to the project documentation, Apple’s licensing terms limit this scenario to two guest instances per host.

All of these workloads are managed through the same daemon and command-line interface.

That broader ambition explains why ArcBox describes itself as an open-source alternative to Docker Desktop and OrbStack rather than simply a sandbox for Claude Code. The repository is available under a dual MIT or Apache-2.0 licence and, as of 4 September 2026, has around 3,100 GitHub stars, up from roughly 2,900 as the project began attracting wider attention.

AI Agents Are Turning the Sandbox Into Part of the Infrastructure

ArcBox also reflects a broader shift taking place around coding agents.

When an assistant only generates text, the main risk concerns the quality and correctness of its response. Once that same system receives tools to use a terminal, modify repositories, download software, and execute programs, runtime security becomes part of the agent architecture.

The question is no longer simply what the model can do. It also becomes a question of where it is allowed to do it.

Containers, microVMs, temporary credentials, restricted networks, disposable filesystems, and access policies may become as important as the model itself.

ArcBox brings that idea to the developer’s desktop. Instead of repeatedly asking whether Claude should be allowed to perform the next action, it gives the agent a machine where it can operate with considerably more freedom and which can later be discarded.

This does not remove the need to control which secrets, repositories, or network connections are provided to the agent. Nor does it make autonomous execution risk-free. But it points towards an interesting direction for the next generation of AI coding tools: less security dependent on a human clicking “Allow”, and more security enforced by the infrastructure surrounding the agent.

Frequently Asked Questions

What is ArcBox?

ArcBox is an open-source runtime for macOS written in Rust that can run containers, Kubernetes, agent sandboxes, and Linux and macOS virtual machines through a common daemon and CLI.

How does ArcBox isolate Claude Code?

abctl claude runs Claude Code inside a disposable Firecracker-based microVM. The sandbox has its own kernel and filesystem and, according to the project, does not mount host files by default.

Can ArcBox replace Docker Desktop?

The project describes itself as an open-source alternative to Docker Desktop and OrbStack and provides a Docker-compatible engine. It remains in public beta, however, so its maturity and compatibility should be assessed for each environment.

What Mac is required to run ArcBox agent sandboxes?

The sandbox functionality, including abctl claude, currently requires an Apple Silicon M3 or newer Mac running macOS 15 or later because it relies on nested virtualisation.