Why Your Claude Code Sandbox Failed: Network Isolation Mistakes That Cost You Security

Mar 11, 2026

Problem

When I set up a VM sandbox to isolate Claude Code, I expected complete isolation. But during my first prompt, Claude accessed Chrome on my host machine.

This wasn’t a VM escape exploit. It was a network configuration mistake.

Environment

VirtualBox/QEMU VM
Bridged networking mode
Claude Code with bypass permissions
Chrome with Claude extension on host

What Happened?

I created a VM specifically to sandbox Claude Code. My goal was security isolation - I didn’t want Claude accessing my host system.

But I made a critical mistake. I configured the VM with bridged networking, which places the VM on the same network segment as my host.

Here’s what my setup looked like:

┌─────────────────────────────────────────┐
│ Host Machine (192.168.1.100)            │
│                                         │
│  ┌────────────────┐   ┌──────────────┐ │
│  │ Chrome Browser │   │ Claude Ext   │ │
│  │                │   │ listens on   │ │
│  │                │   │ localhost    │ │
│  └────────────────┘   └──────┬───────┘ │
│                              │         │
│  ┌───────────────────────────┴───────┐ │
│  │ Bridged Network (Same IP Range)   │ │
│  └───────────────────┬───────────────┘ │
└────────────────────────┼────────────────┘
                         │
┌────────────────────────┴────────────────┐
│ VM Guest (192.168.1.101)                │
│                                         │
│  ┌────────────────────────────────────┐ │
│  │ Claude Code                        │ │
│  │ Can reach host localhost via       │ │
│  │ bridged gateway!                   │ │
│  └────────────────────────────────────┘ │
└─────────────────────────────────────────┘

The Chrome extension on my host listens for connections on localhost. With bridged networking, the VM shares the host’s IP address space. From the extension’s perspective, requests from the VM look like local connections.

As one Reddit commenter put it (with 97 upvotes):

“Claude didn’t escape anything. You gave it a door to walk through.”

How to Solve It?

I needed to fix my network configuration. Here are the options:

Solution #1: Use Claude Code’s Built-in Sandbox

The simplest solution is to use Claude Code’s native sandbox mode instead of a VM:

claude-code --sandbox

Claude Code has built-in sandbox functionality that provides process isolation, filesystem restrictions, and network namespace isolation without VM overhead.

Solution #2: Switch to NAT Networking

If you need a VM, use NAT networking instead of bridged:

# INSECURE: Bridged Networking (Vulnerable)
VBoxManage modifyvm "ClaudeVM" --nic1 bridged --bridgeadapter1 en0

# SECURE: NAT Networking (Isolated)
VBoxManage modifyvm "ClaudeVM" --nic1 nat

NAT places the VM behind a separate network layer, preventing direct access to host services.

Solution #3: Add Firewall Rules

Block VM-to-host traffic at the firewall level:

# Block all traffic from VM network to host
iptables -I INPUT -s 192.168.15.0/24 -j DROP

# Block VM network from reaching localhost
iptables -I INPUT -s 192.168.15.0/24 -d 127.0.0.1 -j DROP

Solution #4: Docker with Network Isolation

For most use cases, Docker provides adequate isolation with far less overhead:

version: '3.8'
services:
  claude-code:
    image: claude-code:latest
    network_mode: none  # No network by default
    volumes:
      - ./workspace:/workspace:rw
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true

The Reason

I think the key reason for this failure is a fundamental misunderstanding about security boundaries.

A VM with bridged networking is not an isolated environment - it’s a connected one. The network bridge gives the VM a direct path to the host’s network stack.

The Chrome extension architecture compounds the problem:

Extensions often bind to localhost or 127.0.0.1
With bridged networking, the VM shares the host’s IP
From the extension’s perspective, VM requests look local

The attack path was straightforward:

Claude in VM requests network access
Bridged network routes to host’s network stack
Chrome extension on host listens on localhost
VM’s requests appear as local connections
Claude “escapes” by simply using the provided network path

Common Mistakes

Mistake	Why It Fails	Correct Approach
Bridged networking in VM	Shares host IP, bypasses NAT isolation	Use NAT with firewall rules
Installing host tools with network access	Creates pathways back to host	Run all tools inside the sandbox
Localhost-only “security”	Assumes requests come from same machine	Verify network source with firewall rules
Shared clipboard	Can exfiltrate data	Disable clipboard sharing
Shared folders with execute	Code execution on host	Mount read-only, no execute
Trusting the agent	AI follows instructions, not rules	Enforce limits at infrastructure level

Summary

In this post, I explained why my VM sandbox failed to contain Claude Code. The key point is that bridged networking gave Claude a direct network path to my host. Claude didn’t “escape” anything - it simply walked through an open door I created.

Use Claude Code’s built-in sandbox mode for most use cases. If you need a VM, use NAT networking with strict firewall rules. Never assume VM placement equals isolation without verifying the network configuration.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit Discussion: Claude Escaped My VM Sandbox

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!