I recently started using Docker Sandbox with Claude Code. Initially, I was running everything directly on my machine. It worked. But it didn’t feel right.

The problem with running Claude Code directly

Claude (or any AI coding agent) is powerful.

It can:

  • Run commands
  • Install dependencies
  • Modify files
  • Execute scripts

Which also means:

It can do things you didn’t explicitly plan.

And this is where the discomfort starts.

What I didn’t like

  • It has access to my full filesystem
  • It can accidentally break local setup
  • Hard to trust generated scripts blindly
  • Mixing “experiment” with “real environment”

It’s similar to something I strongly believe:

Just because something works doesn’t mean it’s the right way.

Enter Docker Sandbox

Instead of running Claude Code directly, I started using:

docker sandbox run claude

What this does is simple (but powerful):

  • Creates a separate Docker daemon
  • Runs inside an isolated VM
  • No direct access to your machine

Think of it as:

A safe playground for AI to do whatever it wants

What actually changes

When you use sandbox, something interesting happens.

Run this:

docker context ls

You’ll see something like:

default
desktop-linux
claude-xyz   ← new context

That claude-xyz is where everything runs.

Not your machine.

Not Docker Desktop.

A completely separate world.

Why this matters (more than you think)

We are entering a phase where:

  • Code is generated
  • Commands are suggested
  • Scripts are auto-executed

And we often just press “Enter”.

That’s risky.

With sandbox

  • If something breaks → it breaks inside sandbox
  • If something malicious runs → it stays contained
  • Your system stays clean

The biggest limitation

You cannot open your app in browser.

If your app runs on:

http://localhost:3000

It won’t work on your Mac.

Because that “localhost” belongs to sandbox.

Why this is actually intentional

Sandbox is built for:

  • Isolation
  • Security
  • Controlled execution

Not for:

  • Local development UX
  • Browser testing

And that’s a good trade-off.

My workaround (simple and practical)

I don’t try to force one tool to do everything.

Instead, I follow this:

1. Development → Docker Desktop

docker run -p 3000:3000 my-app
  • Easy debugging
  • Browser access
  • Full visibility

2. AI execution → Sandbox

docker sandbox run claude
  • Safe execution
  • No risk to local machine
  • Clean environment every time

When you should definitely use sandbox

  • Running AI-generated code
  • Trying unknown scripts
  • Building automation agents
  • Experimenting without trust

Final thought

We used to worry about:

  • Running random .sh files
  • Copy-pasting unknown scripts

Now we are running AI-generated commands at scale.

The risk is higher.

The solution should also evolve.

Docker Sandbox is not perfect.

But it solves a very real problem:

Separation between “trusted environment” and “experimental execution”

And honestly, that’s enough reason for me to use it.

If you are using AI tools for coding, try this setup once.

You might not go back.