DevCell

Claude Code, without the blast radius.

Why DevCell?

AI coding agents need root-level access to be productive: they install packages, rewrite configs, delete files. If you let them do that on your actual machine, one bad tool call can wreck your environment. If you lock them down with permission prompts, you lose the speed that makes agents useful.

DevCell gives agents a full sandbox with zero permission prompts. Your toolchain, your Claude config, your MCP servers: all carried over. Your host filesystem, SSH keys, and credentials: unreachable.

"Run this in a container, not your actual machine."
-- Anthropic, Claude Code docs

Quickstart

Prerequisites: Docker Desktop, OrbStack, Colima, Rancher Desktop, or Docker Engine.

brew install devcell-sh/tap/devcell
cd your-project
devcell claude

On first run, devcell creates devcell.toml and .devcell/ in your project directory, then builds the image (~5 min). Also: devcell codex, devcell opencode, devcell gemini.

What you get

After devcell claude (or codex, opencode, gemini):

Container sandbox with full auto-approve

Every devcell <agent> runs inside an isolated cell. SSH keys, other repos, and host credentials are unreachable. The container is the guardrail, not the approval loop. Agents run with no permission prompts: the sandbox makes it safe, the speed makes it worth it.

MCP servers with backing tools

You don't install MCP servers; they come ready. 86% of MCP servers need local binaries that break on PATH mismatches and missing system libs. Here, the backing tools ship too: the agent can run tofu plan or edit PCBs because OpenTofu and KiCad are installed, not just their MCP servers.

Your setup carries over

CLAUDE.md, hooks, skills, and MCP config mount into the cell. Claude Max/Pro works out of the box: no API key, no proxy, no workarounds. No account or login required.

Also: three OS engines (Linux container, macOS VM, Windows VM^e) | egress lockdown with --solitary | 1Password secrets on RAM-only tmpfs | session handoff for authenticated browsing

Comparison

Use Docker Sandboxes for microVM isolation or cloud-hosted sandboxes. Use E2B for ephemeral cloud sandboxes with an SDK. Use Microsandbox for libkrun microVMs. Use DevCell when the agent needs full auto-approve with your toolchain and Claude setup intact, and no account or cloud dependency.

Stacks

Batteries included, everything swappable. Stacks and modules are defined in devcell-sh/home. Use them as-is, extend with modules, or fork and build your own. Base images and nix cache published to ghcr.io/devcell-sh/devcell (linux/amd64 + linux/arm64); devcell build layers your project config on top.

Set stack = "ultimate" in devcell.toml or run devcell build --stack ultimate.

Add-on modules (set modules = ["android"] in devcell.toml):

Full package list and more stacks in devcell-sh/home. Fork it, edit one Nix file, run devcell build.

Engines and guests

The guest is the OS inside the cell (--os); the engine is how the cell runs (--engine). Pick the guest and the engine follows:

devcell claude --os macos       # open Claude Code in a macOS VM
devcell build --os windows --experimental=engine-windows   # build the Windows VM image (experimental)

Set permanently in devcell.toml:

[cell]
os = "macos"

MCP servers

Two layers, both work:

• Your servers - anything you add with claude mcp add or put in .mcp.json carries over into the cell. Your config is preserved.
• Nix-baked servers - auto-merged into the agent's config at container startup. The backing tools ship alongside: the agent can run tofu plan, analyze PCBs, or edit SVGs because OpenTofu, KiCad, and Inkscape are installed, not just their MCP servers. Pinned to commit hashes in the nix flake, so rebuilds get the same versions.

Headline servers: OpenTofu (IaC), KiCad (PCB analysis), Inkscape (SVG), Yahoo Finance, EdgarTools (SEC filings), FRED API, Google Maps, Linear, Notion. 11 servers total. Full list and auth requirements in devcell-sh/home.

Security

• Project directory mounted at /<cellName> and at its original host path (e.g. /Users/alex/dev/api-backend). $DEVCELL_PROJECT_DIR points to /<cellName>. Host filesystem outside the project is unreachable
• SSH keys, .env files outside the project, and host credentials are not mounted unless explicitly configured via [cell] volumes
• Session user runs without root privileges
• 1Password secrets injected at runtime, never persisted
• GPG isolation per container (prevents SQLite lock contention)
• Gitleaks pre-commit hook and CI secret scanning

Found a vulnerability? See SECURITY.md for reporting instructions.

Configuration

Project config at devcell.toml (created by devcell init or first run) with JSON Schema for editor validation and completion. Optional global defaults at ~/.config/devcell/devcell.toml. See devcell --help for the full reference.

WireGuard tunnels

Add one [[wireguard]] block per tunnel to devcell.toml with a standard wg-quick config. The container gets NET_ADMIN, /dev/net/tun, and brings the tunnel up at start. Secrets never land in the config file on disk:

• WG_PRIVATE_KEY (required): the [Interface] private key. Any inline PrivateKey is stripped and loaded from this variable at runtime.
• WG_PRESHARED_KEY (optional): applied to every [Peer] in the tunnel. Any inline PresharedKey is stripped the same way. Peers with different PSKs are rejected at validation time, so use one tunnel per PSK.

Set both in the host environment where you run devcell. When a tunnel is enabled they are forwarded into the container by name (values never appear in the docker run command line), written to a /run/secrets tmpfs, and applied with wg set after the interface is up. No manual PostUp is needed.

When you need more

• Runtime versions - .tool-versions or mise.toml, no rebuild
• Extra packages - devcell.toml then devcell build
• Full control - .devcell/flake.nix for nix packages
• Org-wide stacks - fork devcell-sh/home, point your flake to your fork

Building images

Local development uses devcell build — task image:* is for CI/release only.

devcell build                    # Rebuild the local cell image from this checkout
devcell build --update           # Bump nix flake inputs + rebuild
devcell build --thin             # Incremental, mounts nix store on a Docker volume
task image:pure:build         # CI/release: build pure base + ultimate
task image:impure:build       # [DEPRECATED] legacy Dockerfile path, kept one release

Testing

Tests use testcontainers-go and require Docker.

task test                     # Short mode - uses pre-built image
go test -v -timeout 600s ./test/...   # Long mode - rebuilds image first

Nix modules

The image is built from composable Nix home-manager modules in the devcell-sh/home repo, assembled into stacks. Validate after edits:

task nix:validate    # Syntax check + attribute resolution across all stacks

Terminology

One-line model: a workspace is the boundary; many projects live inside it; each project spawns one or more cells.

Experimental features

Off by default. Turn one on with --experimental=<name>, DEVCELL_EXPERIMENTAL=<name> or [cell] experimental = ["<name>"]; several are comma-separated. Experimental features may change or go away without a deprecation cycle.

Run devcell experimental to see what is on. Details, lifecycle and how to add one: docs/experimental.md.

Not yet

Contributing

Contributions welcome. See CONTRIBUTING.md for setup, rules, and PR expectations. CHANGELOG.md tracks releases.

License

Apache 2.0