Is a devcontainer enough for AI coding agents?

01What does a devcontainer isolate for an AI coding agent?

A development container is a Docker container described by a devcontainer.json file in the repository. An editor that supports the spec, such as VS Code, a JetBrains IDE, Cursor or GitHub Codespaces, connects to it, and the terminal, language servers and build tools run inside. Anthropic's Claude Code documentation puts the benefit plainly: commands Claude runs execute inside the container rather than on the host, while edits to project files appear in your local repository, because the project folder is bind-mounted in.

That is a real improvement over running an agent directly on a laptop. A stray rm -rf hits the container's file system, not your home folder, and the toolchain is the same for every engineer. But a container is a set of namespaces and control groups on a shared kernel, not a separate machine, and the bind-mounted workspace is your real working copy. Anything the agent deletes or rewrites there is deleted or rewritten on the host too.

Anthropic is direct about the limit. Its devcontainer page warns that when Claude Code runs with --dangerously-skip-permissions, a dev container does not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude. It recommends dev containers only for trusted repositories, and says to avoid mounting host secrets such as ~/.ssh or cloud credential files.

02Where do credentials live inside a devcontainer?

Usually in several places at once. Claude Code keeps its authentication token under ~/.claude, and Anthropic's guide shows how to persist that folder across rebuilds with a named volume. Cloud provider credentials are passed in as environment variables through containerEnv or a Codespaces secret, which Codespaces exposes as environment variables inside the container. Each of those is readable by every process the agent starts, including packages it installs and scripts a prompt injection talks it into running.

The editor adds more. Microsoft's Dev Containers documentation says the extension reuses your local Git credential helper, so credentials entered locally work in the container and the other way round; it forwards your local SSH agent when one is running; and it copies your .gitconfig in on startup. That is convenient for a developer and means a hijacked agent inside the container can push with your Git identity or sign in over SSH with your keys, without ever reading a key file.

• ~/.claude: the agent's own sign-in token.
• containerEnv and Codespaces secrets: API keys and cloud credentials as environment variables.
• Git credential helper and SSH agent forwarding: your Git and SSH identity, usable from inside.
• Anything else mounted in: Anthropic's advice is to prefer repository-scoped or short-lived tokens.

03What does the devcontainer firewall block, and what does it leave open?

Anthropic's reference container ships an init-firewall.sh script, and it needs the NET_ADMIN and NET_RAW capabilities to run. As published, it sets the default output policy to drop, builds an ipset from GitHub's published address ranges plus the addresses that registry.npmjs.org, api.anthropic.com, sentry.io, statsig.com and the VS Code marketplace hosts resolve to when the script runs, and rejects everything else. It then checks that example.com is unreachable and api.github.com is reachable.

Reading the script also shows what stays open, which is worth knowing before you rely on it. It allows outbound DNS on UDP port 53 and outbound SSH on TCP port 22 to any destination, and it accepts traffic to and from the host's /24 network. DNS to any server is a known exfiltration channel, and every GitHub address range is reachable, which includes services that accept uploads. Addresses are resolved once at start, so a provider that changes addresses later is refused, while a shared address admits every site served from it. The rules live in the container's own iptables, so they hold for as long as the agent cannot become root inside it.

One more structural point: the repository writes the boundary. Under the Dev Container spec, initializeCommand runs on the host machine, and runArgs, mounts, capAdd and privileged all come from the repository's devcontainer.json. Anthropic notes the same about policy files copied in by a Dockerfile: anyone with write access to the repository can change or remove that step. For your own trusted code that is fine. For an untrusted clone, opening its devcontainer means running its configuration.

04How are Docker Sandboxes different from a devcontainer?

Docker Sandboxes, driven by the sbx CLI, take a different shape. Docker's security documentation says each sandbox runs in a microVM with a separate kernel and no shared memory or processes with the host, and has its own Docker Engine with no path to the host daemon. Outbound TCP is governed by a deny-by-default policy and goes through a proxy on the host; UDP is blocked unless an experimental setting is turned on, and ICMP is blocked.

The biggest difference for coding agents is credentials. Docker documents that a host-side proxy injects API keys into HTTP headers and that the raw credential values never enter the VM: the agent sends a sentinel value, and the proxy swaps in the real key after the request has left. Docker also flags a limit of its own: the default allowed domains include broad wildcards such as *.googleapis.com, and sbx policy ls shows what is allowed. The workspace is mounted through a file-system passthrough at the same path as on the host, so changes are instant in both directions, as with a devcontainer.

05Devcontainer vs VM: which questions decide it?

None of these is the wrong tool. A devcontainer is a good fit for team consistency on trusted code, especially with prompts left on. A microVM with a host-side credential proxy fits when the repository, its issues or its dependencies are not yours, or when the agent runs unattended. A full VM in UTM or Lima is another option when you want a whole separate machine and are happy to manage it.

The labels matter less than the answers to four questions, and they are worth asking of any setup, including one you already run.

• Where do the keys live? Inside the boundary, they are readable by whatever runs there. Outside it, they can only be spent through the proxy.
• Who writes the boundary? A devcontainer.json in the repository, or a configuration you keep yourself.
• What is the way out? Check DNS, SSH and broad allowed domains, not only HTTPS.
• What does undo look like? A bind-mounted workspace changes the real folder; plan for Git or snapshots.