Let’s Talk About Claude Code, Part 2: Container or Sandbox VM?

In Part 2 of the series, the focus shifts from dev containers to Docker Sandboxes (sbx). The writer explains how sbx addresses two main gaps left by dev containers: shared kernel and running Docker inside Docker. When using a container, the kernel is shared, meaning that if anything breaks out, it can affect the host system and access credentials. Additionally, running Docker inside Docker can lead to the agent having access to the host's filesystem, which is a significant security risk.

Sbx resolves these issues by providing each agent with its own microVM, complete with its own kernel and Docker engine. This way, the agent can run the entire stack without interfering with the host system. Outbound traffic is controlled by a network policy, allowing the user to specify what the agent can access.

During operation, git credentials are injected by a proxy, ensuring that sensitive tokens never sit inside the VM. However, there are trade-offs to consider. Since the default setup skips permission prompts, users must develop the habit of not approving on autopilot. Instead, the boundary is replaced with a hard boundary, which must be properly configured.

Two less obvious areas affected by the shared project folder include git history and files written by the agent that can run on the host. This means that reset commands, deleted .git folders, and executing files after a sandboxed session can all impact the host. To mitigate these risks, users can opt for sbx's clone mode (--clone), which creates a separate git clone for the agent, keeping the host checkout untouched until explicitly fetched.

Lastly, the writer highlights the importance of network rules, emphasizing that agents should only be allowed to reach specified resources. The next step is to determine what should be on the allowlist for package registries and third-party APIs, prompting the reader to consider their own sandboxing strategy.