Dev Container Generator

Why run Claude Code in a dev container

A dev container is a reproducible, disposable environment defined by a single devcontainer.json file. Everyone who opens the repo gets the exact same toolchain - same language version, same CLI tools, same extensions - without touching their own machine. For Claude Code specifically there are two big wins: the model runs inside an isolated container instead of your real filesystem, and the whole team shares one setup so 'works on my machine' stops being a debugging step.

The generator above builds that file for you. Pick a base image, choose a language version, toggle the dev container features and VS Code extensions you want, and optionally have Claude Code install itself the moment the container is created. The output is valid devcontainer.json you drop into a .devcontainer folder.

The pieces of a devcontainer.json

• image - the prebuilt container to start from. The Microsoft dev container images cover Node, Python, and multi-language stacks with sane defaults.
• features - reusable add-ons published as OCI artifacts. Adding the git, github-cli, or docker-in-docker feature is a one-line entry instead of a custom Dockerfile.
• customizations.vscode.extensions - the editor extensions that auto-install inside the container so every teammate gets the same linting and tooling.
• forwardPorts - ports the container exposes to your host, so a dev server inside the container is reachable in your browser.
• postCreateCommand - a command that runs once after the container is built, ideal for installing dependencies and Claude Code itself.
• remoteUser - the user the tools run as. Running as a non-root user like 'node' is the safer default.

Installing Claude Code on container create

When you toggle the Claude Code install option, the generator appends the global npm install to the postCreateCommand. That means the very first time the container spins up, it installs your dependencies and then pulls Claude Code, so it is ready to run the moment the container finishes building. You will still authenticate on first use, but the binary is already there.

Features versus a custom Dockerfile

For most projects, base image plus features is all you need and it keeps the config declarative and short. Reach for a custom Dockerfile only when you need system packages or a build step that no published feature covers. The two approaches compose: you can point at a Dockerfile and still layer features on top. Starting from features first keeps your setup readable and easy for teammates to reason about.

How to use the output

1. Create a .devcontainer folder in your project root.
2. Save the generated JSON as .devcontainer/devcontainer.json.
3. In VS Code, run 'Dev Containers: Reopen in Container', or open the repo in a GitHub Codespace.
4. Wait for the postCreateCommand to finish - that is when dependencies and Claude Code install.
5. Run claude in the integrated terminal and authenticate on first use.

Keeping it reproducible over time

Pin your image tags and feature versions rather than floating on latest, so a rebuild six months from now produces the same environment. Commit the devcontainer.json so the setup travels with the repo. When you upgrade a language version, do it in the file and let everyone rebuild - that single-source-of-truth discipline is the whole reason dev containers exist.