Running Claude Code in a dev container: isolated, consistent, fewer prompts
TL;DR
A dev container gives Claude Code an isolated environment that's the same for the whole team. Mount a volume and set CLAUDE_CONFIG_DIR to keep your login; skip permission prompts only with trusted repos, never mount host secrets, and restrict egress.
You want Claude Code to run for a long time without approving every command, but you're wary of giving it full rein over your real machine. Or your team needs identical environments for everyone. A dev container solves both: Claude Code runs inside a predefined Docker container, the commands it runs stay in the container, while the project files it edits still appear in your local repo. It's the most common way to run Claude Code more safely with fewer permission prompts.
Adding Claude Code to a dev container
// .devcontainer/devcontainer.json
{
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
}
}
Rebuild the container (VS Code: Dev Containers: Rebuild Container), open a terminal, run claude and sign in. The feature installs Node.js if the image lacks it, and adds the Claude Code extension when opened in VS Code or Codespaces. It works with any tool that supports the Dev Containers spec: VS Code, GitHub Codespaces, JetBrains, Cursor.
Keeping your login across rebuilds
"mounts": ["source=claude-code-config,target=/home/node/.claude,type=volume"],
"containerEnv": { "CLAUDE_CONFIG_DIR": "/home/node/.claude" }
Without CLAUDE_CONFIG_DIR, ~/.claude.json sits outside the volume and is discarded on rebuild, so you repeat setup every time. To isolate per project, add ${devcontainerId} to the volume name.
Four main configuration topics
| Goal | How |
|---|---|
| Enforce organisation policy | Copy managed-settings.json to /etc/claude-code/ in the Dockerfile |
| Pin a version, disable auto-update | Install with npm install -g @anthropic-ai/[email protected], set DISABLE_AUTOUPDATER=1 |
| Restrict network egress | The reference container's init-firewall.sh, needing NET_ADMIN and NET_RAW capabilities |
| MCP servers for the team | .mcp.json at the repo root, with required binaries installed in the Dockerfile |
Running without permission prompts: how safe?
In a container running as a non-root user, you can use --dangerously-skip-permissions (the CLI rejects the flag when run as root). But the docs warn plainly: a container doesn't stop a malicious project from exfiltrating anything accessible inside it, including Claude Code credentials in ~/.claude. Claude can still modify any file in the bind-mounted workspace (which appears directly on your host) and reach anything the network policy allows.
- Use it only with trusted repositories, and monitor Claude's activity.
- Don't mount
~/.sshor cloud credential files from the host; use short-lived, repository-scoped tokens. - Pair it with network egress restrictions to limit what a bypassed session can reach.
- For fewer prompts with safety checks still on, consider auto mode instead of bypass.
The reference container
The anthropics/claude-code repository includes a sample .devcontainer/ with devcontainer.json, a Dockerfile and init-firewall.sh, combining the CLI, a firewall and persistent config volumes. It's a working example, not a maintained base image.
How to apply it
- Dev: Add the Claude Code feature to your project's existing devcontainer; mount a config volume so you don't sign in again.
- Tech Lead: Use the reference container as a starting point for automated agent environments with an allowlist firewall.
- PM/Admin: Deliver mandatory policy via server-managed settings or MDM, since anyone with write access to the repo can edit the Dockerfile.
Sources & references
- Development containers — Claude Code Docs