Why I Run My AI Coding Assistant in a Docker Container (And Why You Should Too)

Let's be honest with ourselves about AI coding agents. Either you've disabled all the safety rails and let your agent run wild on your machine, or you're sitting there clicking "Approve" every thirty seconds like you're defusing a bomb. Both approaches suck in different ways.

I used to be the guy clicking approve. And honestly? That was me being a responsible adult. But it was absolutely brutal on my productivity. Every time Claude Code wanted to run a bash command, install a package, or modify a file, I'd get yanked out of flow state to babysit the process.

Then I watched friends go the opposite direction—fully YOLO mode, no guardrails, just vibes and prayer. And honestly, that scared me even more. These agents are powerful, but they're also autonomous enough to do real damage if something goes sideways.

The middle ground that changed everything for me: containerizing the coding agent itself.

The Basic Idea

Instead of running your AI coding assistant directly on your host machine, you spin it up inside a Docker container with the workspace directory mounted in. The agent does its thing inside the container, where its destructive capabilities are contained. If it decides to delete everything? Cool—it's deleting the container's filesystem, not your actual machine.

This means you can actually use YOLO mode features like --dangerously-skip-permissions without the existential dread of watching your home directory disappear.

Let me show you how this works.

Setting Up Claude Code in Docker

The simplest setup starts with a Dockerfile. Here's what you're looking at:

FROM node:20-bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://claude.ai/install.sh | bash

ENV PATH="/root/.local/bin:${PATH}"

WORKDIR /workspace

ENTRYPOINT ["claude", "--dangerously-skip-permissions"]

Build it once:

docker build -t claude-code .

Then run it with your current directory mounted:

docker run -it -v "$PWD:/workspace" claude-code

And just like that, you've got Claude Code running with access to your project files. The container can read, write, and execute freely within the workspace, but it's sandboxed away from your actual system.

The Authentication Problem

Here's where things get interesting. On Mac, Claude Code stores credentials in Keychain. Linux containers don't speak Keychain. So you need to handle authentication differently.

The solution is to pass an API token as an environment variable. First, grab your setup token:

claude setup-token

Then create a small entrypoint script that reads this token and configures the container's credentials file:

#!/bin/bash
echo "${ANTHROPIC_TOKEN}" > /root/.claude/credentials.json
exec claude --dangerously-skip-permissions

Now when you run the container, you just pass the token:

docker run -it -v "$PWD:/workspace" -e ANTHROPIC_TOKEN="$(claude setup-token)" claude-code

Making It Actually Convenient

Let's be real—you don't want to type all that every time. Create an alias or a shell function:

cc() {
    docker run -it \
        -v "$PWD:/workspace" \
        -v "$HOME/.claude:/root/.claude" \
        -v "$HOME/.claude/skills:/root/.claude/skills" \
        -v "$HOME/.claude/settings.json:/root/.claude/settings.json:ro" \
        -e ANTHROPIC_TOKEN="$(claude setup-token 2>/dev/null)" \
        --env-file ~/.claude/env \
        claude-code "$@"
}

This setup:

• Mounts your current directory as /workspace
• Passes through your Claude config and skills
• Loads environment variables (useful for API keys the agent might need)
• Lets you call cc from anywhere and immediately have a working coding agent

What This Doesn't Protect You From

I want to be crystal clear about the threat model here. Containerization protects your host machine from the agent's actions. It does NOT protect you from:

• Prompt injection attacks: If an attacker can influence what the agent sees, they might trick it into exfiltrating your code or secrets
• API key exposure: The agent still has access to any keys it can read in the workspace or environment
• Network-based attacks: The container still has network access
• Supply chain issues: Malicious packages the agent installs in the container are still malicious

What you're gaining is protection against "oops, the agent deleted my home directory" or "it ran rm -rf / and now I'm toast." For me, that's been worth the setup overhead many times over.

Is This Overkill?

Honestly? Depends on what you're doing. For quick scripts and one-off tasks, I still just use Claude Code directly with the normal permission prompts. But for any serious feature development, refactoring work, or when I'm working in a repo I care about? The container setup has saved me hours of aggregate approval-clicking and given me genuine peace of mind.

The best part is that once you understand the concept, you can adapt it. Different coding agents will have different gotchas—credential storage locations, config formats, entrypoint requirements—but the underlying principle stays the same: isolate the agent, give it controlled access to your work, and let it run without you hovering over its shoulder.

Wrapping Up

We're in an interesting transition period with AI coding tools. The safety defaults are conservative for good reasons—these agents are powerful and autonomous. But conservative defaults often mean "designed for people who are trying the tool out" rather than "designed for daily professional use."

Containerization is one way to bridge that gap. It's not perfect security, but it's practical protection that lets you actually capture the productivity gains these tools offer without playing permission whack-a-mole.

Give it a shot. Once you've got the alias set up and you're calling cc from your terminal to get a fully loaded coding agent in seconds, you won't go back.

What's your setup for running AI coding agents? Still clicking approve? Fully YOLO? Got a containerization trick I missed? I'd love to hear how others are thinking about this balance.