Skip to content
BSWEN
Blog

Don't Let Claude Code Touch Your Computer: Sandbox AI Agents Before They Break Things

Cowrie
Cowrie
Dev @ Bswen

The Problem

I let Claude Code run freely on my MacBook. It seemed safe enough—I was just automating some routine tasks. Then one afternoon, I watched in horror as Claude deleted an entire project directory. Not the one I asked it to work on. A different one. It misunderstood my context and executed rm -rf on the wrong path.

My .env files with API keys? Gone. My SSH configurations? Exposed in terminal output. My weeks of work? Irrecoverable.

This isn’t a hypothetical scenario. It’s exactly what the Reddit community on r/ClaudeAI has been warning about:

What users report
- Agents "fail in weird ways"
- They misunderstand context and take wrong actions
- They continue executing when they should stop
- Damage can be irreversible on bare metal

The top comment on every safety discussion: “Run it in a VM or a Docker container.”

Why This Happens

Claude computer-use agents aren’t deterministic. They interpret your instructions through layers of reasoning. When that reasoning goes wrong, the actions go wrong too.

Failure modes
┌──────────────────────────────────────────────────────────────────┐
│                                                                  │
│  Your Intent → Claude's Interpretation → Action → Result        │
│                                                                  │
│  What you meant: "Clean up the temp files in ./project"          │
│  What Claude thought: "Remove everything in the current dir"     │
│  What happened: Deleted your entire workspace                    │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

The key issue: Claude has access to your entire system when running on bare metal. Files, network, environment variables, installed tools. Everything.

The Solution: Isolation Layers

The community consensus is clear: sandboxing is table stakes for competent users. There are three practical approaches:

Option 1: Docker Containers (Lightweight)

Docker gives you process-level isolation with minimal overhead:

Basic Docker setup
# Create a workspace container
docker run -v ./my-project:/workspace -it ubuntu:22.04


# Inside the container, Claude can only see /workspace
# Your home directory, SSH keys, other projects stay protected

The key principle: only mount what Claude needs:

Safe mount strategy
docker run \
  -v ./specific-project:/workspace:rw \
  -v ~/.claude/config:/claude-config:ro \
  --network none \
  -it claude-workspace


# --network none: No internet access from container
# :rw only on workspace, :ro on config
# No access to ~/.ssh, ~/.env, or other sensitive paths

I never mount my home directory. I never mount paths containing credentials. I mount only the specific project directory Claude should work on.

Option 2: Virtual Machines (Full Isolation)

For maximum safety, use a VM. Complete hardware-level isolation:

VM isolation benefits
┌─────────────────┐     ┌─────────────────┐
│  Your Mac       │     │  Guest VM       │
│                 │     │                 │
│  ~/.ssh         │  ✗  │  Claude runs    │
│  ~/.env         │  ✗  │  here           │
│  Other projects │  ✗  │                 │
│  System configs │  ✗  │  Can't escape   │
│                 │     │  the VM         │
└─────────────────┘     └─────────────────┘

VM setup options:

  • UTM on Mac: Free, works well for ARM-based Macs
  • VirtualBox: Cross-platform, mature tooling
  • VMware: Enterprise features, GPU passthrough available

For GPU-intensive tasks (if Claude needs local LLM inference), VMs with GPU passthrough are necessary. Docker can’t passthrough GPU easily on Mac.

Option 3: Devcontainers (VS Code Integration)

VS Code’s devcontainer feature is designed for exactly this use case:

devcontainer.json
{
  "name": "Claude Workspace",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached"
  ],
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {}
  },
  "customizations": {
    "vscode": {
      "extensions": ["ms-vscode-remote.remote-containers"]
    }
  }
}

One Reddit user shared their devcontainer skill:

“I can let Claude Code snoop around without compromising my file system. It sees only what’s in the devcontainer.”

The devcontainer approach gives you:

  • Automatic isolation when opening a project
  • Pre-configured environment
  • Easy reset (just delete and recreate container)
  • VS Code integration for debugging

What Each Approach Protects

Protection comparison
| Threat              | Docker | VM  | Devcontainer |
|---------------------|--------|-----|--------------|
| File deletion       | Partial| Full| Partial      |
| Credential exposure | Full   | Full| Full         |
| Network attacks     | Config | Full| Config       |
| System modification | None   | Full| None         |
| GPU passthrough     | Hard   | Easy| Hard         |
| Setup effort        | Low    | High| Medium       |
| Resource overhead   | Minimal| High| Minimal      |

“Partial” means it depends on your configuration. Docker and devcontainers can protect files if you mount carefully.

Common Mistakes

I’ve seen people make these mistakes repeatedly:

Mistake 1: Assuming Sandbox Is Automatic

Dangerous assumption
# This gives Claude access to your entire system
claude-code start


# Many users don't realize:
# - Claude can read ~/.ssh/id_rsa
# - Claude can read ~/.zsh_history
# - Claude can read any file your user can access

No sandbox is created by default. You must create it explicitly.

Mistake 2: Mounting Home Directory

Dangerous mount pattern
# WRONG: Claude can now access everything
docker run -v ~:/home/user -it claude-container


# ~/.ssh, ~/.aws, ~/.gnupg, .env files everywhere
# All exposed to Claude's commands

The correct approach:

Safe mount pattern
# RIGHT: Only the specific project
docker run -v ~/projects/my-app:/workspace -it claude-container


# Claude sees only /workspace
# Your credentials stay invisible

Mistake 3: Passing Credentials Inside Container

Leaking credentials
# WRONG: Environment variables leak secrets
docker run -e ANTHROPIC_API_KEY=sk-ant-... -v ~/project:/workspace ...


# Claude can now:
# - Read the API key
# - Log it to files
# - Send it to external services accidentally

Instead, use volume mounts for secrets:

Credential isolation
# RIGHT: Secrets as read-only mount
docker run \
  -v ~/.config/claude/api-key:/claude-key:ro \
  -v ~/project:/workspace \
  ...


# Claude reads the key file but can't modify or leak it elsewhere
# (assuming you configure Claude to read from that path)

Mistake 4: No Network Restrictions

Claude can accidentally send data to external services. Restrict network access:

Network isolation
# No external network access
docker run --network none -v ~/project:/workspace ...


# Or allow only specific hosts
docker run --network claude-net ...


# Create network with restricted access
docker network create --internal claude-net

My Sandboxing Workflow

Here’s the workflow I use now:

Safe Claude workflow
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  1. Create isolated workspace                                   │
│     docker run -v ./project:/workspace --network none           │
│                                                                 │
│  2. Mount only what Claude needs                                │
│     - Project source code                                       │
│     - Config files (read-only)                                  │
│                                                                 │
│  3. No credentials in container                                 │
│     - API keys via read-only mount                              │
│     - No ~/.ssh, ~/.aws, .env                                   │
│                                                                 │
│  4. Run Claude with explicit scope                              │
│     "Work only in /workspace directory"                         │
│                                                                 │
│  5. Monitor and verify                                          │
│     - Watch terminal output                                     │
│     - Verify files changed only in /workspace                   │
│                                                                 │
│  6. Cleanup                                                     │
│     docker rm container                                         │
│     Fresh container for next task                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

For critical work (production systems, sensitive data), I use a VM instead:

VM workflow
# Spin up a fresh UTM VM
utm start claude-workspace


# SSH into VM (credentials are in VM, not on host)
ssh claude@vm-local-ip


# Claude runs entirely inside VM
# Zero access to host system

Quick Reference Card

Docker isolation quick reference
# Basic safe setup
docker run \
  -v ./project:/workspace \
  -v ~/.claude/config:/config:ro \
  --network none \
  -w /workspace \
  -it ubuntu:22.04


# Inside container, install Claude Code
curl -fsSL https://claude.ai/install.sh | sh


# Run Claude
claude-code start


# When done, destroy container
docker rm -f container-id

The Reason This Matters

AI agents are powerful tools. But power without boundaries is dangerous.

When Claude runs on bare metal:

  • A single misinterpretation can delete months of work
  • Exposed credentials can leak to logs, files, or network
  • Recovery is often impossible

When Claude runs in a sandbox:

  • Misinterpretations affect only the sandboxed project
  • Credentials stay isolated
  • Recovery is trivial: destroy container, start fresh

The Reddit poster who warned about this put it simply:

“Run it in a VM or a Docker container. This is table stakes.”

Summary

In this post, I explained why running Claude computer-use agents on bare metal is dangerous and how to protect yourself. The key points:

  1. Claude agents can misunderstand context and execute wrong commands
  2. Docker containers provide lightweight isolation with careful mount configuration
  3. Virtual machines provide complete isolation for maximum safety
  4. Devcontainers integrate isolation into your VS Code workflow
  5. Never mount home directories, never pass credentials directly, always restrict network

The rule is simple: never let Claude touch your main computer. Give it a sandbox. Your data and credentials stay safe even when agents fail.

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:

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

Comments

Tags: