A containerised sandbox for Claude code

I've been using Claude Code for a few weeks now, watching it navigate codebases and execute commands with impressive competence. It's genuinely helpful – the kind of tool that makes you wonder how you managed without it. But there's this nagging voice in the back of every platform engineer's head that asks uncomfortable questions at 2 AM: What if it decides to explore that .ssh directory?

This wasn't about trust, exactly. Claude has been nothing but reliable. It was more about recognizing that powerful tools deserve careful boundaries. When you've spent years watching production systems fail in creative and unexpected ways, you develop what some might call paranoia but I prefer to think of as healthy skepticism.

That tension between utility and safety is what led me to build claude-sandbox – a Docker container that gives Claude Code room to work while keeping it away from the parts of my system I'd rather it not explore.

What does safe AI assistance actually look like?

The challenge with AI coding tools isn't whether they'll betray you – it's that they're so capable you forget they're essentially running arbitrary code on your machine. That realization hit me while watching Claude effortlessly navigate a complex codebase, and I thought: "This is amazing, but what are the failure modes I haven't considered?". You need to read a file, sure ... er, hang on ... remind me, what was that file you just read and shipped off my machine?

Security in development environments isn't about preventing malicious actors; it's about creating predictable failure boundaries. When something goes wrong – and in software, something always goes wrong – you want to know exactly what's affected and what isn't.

This container setup is simple:

docker build -t claude-sandbox .
docker run -it -v $(pwd):/workspace/${PWD##*/} \
  -v ~/.claude-sandbox/.claude:/home/appuser/.claude \
  -v ~/.claude-sandbox/.claude.json:/home/appuser/.claude.json \
  --network="host" -w /workspace/${PWD##*/} claude-sandbox

This creates a benevolent jail cell for Claude. It can see your current project, run commands, and be genuinely helpful – but it can't accidentally stumble into your SSH keys, environment variables, or that collection of automation scripts sitting over here.

The Docker command becomes more manageable with an alias, because life's too short to type volume mounts repeatedly:

alias claude='docker run -it  \
  -v $(pwd):/workspace/${PWD##*/} \
  -v ~/.claude-sandbox/.claude:/home/appuser/.claude \
  -v ~/.claude-sandbox/.claude.json:/home/appuser/.claude.json \
  --network="host"                \
  -w /workspace/${PWD##*/}        \
  claude-sandbox'

Now claude gives me the AI assistance with clear boundaries – the kind of setup that lets you experiment confidently.

The reality of AI tool safety

I sometimes wonder if I'm being overly cautious. Then I remember the recent Replit incident, where an AI agent deleted an entire company's production database during what should have been a routine task. That's the kind of failure mode that keeps platform engineers awake at night.

The honest truth is that AI tools are powerful enough to cause real damage, even when they're working as intended. It's not about malice; it's about the intersection of capability and unpredictability. Containers provide "graceful failure boundaries" – when something goes wrong, the blast radius is contained and predictable.

The container achieves this through file system isolation, ensuring Claude can only see the current project directory rather than wandering into sensitive areas of your system. Environment protection means no access to shell history, credentials, or system configurations that might contain secrets or personal information. Resource boundaries limit Claude to explicitly granted network and system access, preventing unexpected connections or system modifications. Most importantly, the setup provides predictable failure – when things inevitably go wrong, you know exactly what's affected and what remains untouched.

Living with AI tools safely

I'm not trying to discourage anyone from using AI coding assistants – they're genuinely transformative tools that have changed how I approach development work. But I've also spent enough time in production environments to know that the most dangerous failures are the ones you don't see coming.

This container approach lets you get all the benefits of Claude's assistance while creating clear boundaries around what it can affect. The setup is fast enough that you'll forget about the isolation layer, but it's there when you need it.

The repository includes everything needed to adapt this approach to your own requirements. I built it to be modified rather than used as-is, because security needs are highly contextual. What keeps me awake at night might be completely irrelevant to your environment.

What I find most valuable about this approach is that it removes a category of worry from AI tool usage. You can experiment more freely, try riskier automation, and generally push the boundaries of what's possible when you know the failure modes are bounded and predictable.

Good security shouldn't require constant attention or change how you work. This setup won't transform your development process, but it will let you use AI tools without wondering what they might accidentally break.

And there's more

Blog Edit - 02 AUG

Alternatives exist if you wish to explore this approach more ...

Anthropic provide Development containers with a reference Dockerfile. Similar approach, similar purpose. With devcontainers the volume mounts are set in the devcontainer.json. If you aren't using the devcontainer approach, using the direct mount the docker command is a more lightweight approach.

Dagger's container-use provides a really comprehensive sandboxed dev toolkit, way beyond the simple use case above. Well worth taking a look at if you setting up multiple parallel agents and need the appropriate orchestration control.

Claude Box follows the same foundations, and provides support for more languages and tooling that you may use (and may save you having to customise your own Docker image).