Skip to content
Back to blog
AIDockerDevOps

Lock Claude Code inside Docker

Giving an AI agent access to your terminal is unnerving. A well-configured container lets you keep the speed without betting your machine.

Ismael Catala2 min read

The first time a coding agent ran rm on my machine I felt genuinely uneasy. It didn't delete anything important, but the question was already there: why am I giving it access to my entire disk?

The short answer is that you don't have to. A container solves 90% of the problem in twenty lines.

The Dockerfile

FROM node:22-slim
 
RUN apt-get update && apt-get install -y --no-install-recommends \
    git ca-certificates ripgrep \
    && rm -rf /var/lib/apt/lists/*
 
# An unprivileged user: no working as root
RUN useradd -m -s /bin/bash agent
USER agent
WORKDIR /workspace
 
CMD ["bash"]

What matters isn't the image, it's what you don't mount.

Mount only the project

services:
  agent:
    build: .
    volumes:
      - ./:/workspace
      - agent-cache:/home/agent/.cache
    working_dir: /workspace
    environment:
      - ANTHROPIC_API_KEY
    tmpfs:
      - /tmp
 
volumes:
  agent-cache:

With this the agent sees the repository and nothing else. Not your SSH keys, not your ~/.aws, not the other projects on your disk. If it makes a mistake, it makes it inside a folder that's already under version control.

The details that make the difference

Pass the API key through the environment, never through a mounted file. Notice the variable is declared without a value: Docker Compose picks it up from the host environment and it never gets written anywhere.

Add ripgrep to the image. Agents search through code constantly and the speed difference against recursive grep is enormous on large repos.

Use tmpfs for /tmp. Temporary files live in memory and vanish when the container stops.

Restrict the network if your case allows it. If the agent only has to touch local code, network_mode: none is the perfect cage. Keep in mind it won't be able to install dependencies or call the API, so it's usually more practical to leave networking on and rely on filesystem isolation.

What it doesn't solve

A container does not stop the agent from running git push --force to production if you handed it credentials. Filesystem isolation is one layer, not a replacement for permissions. Check which tokens are in the environment before you start.

I've been working this way for months and I'm far more relaxed. The speed is the same and the unease is gone.

Keep reading