Open Source · Apache 2.0 · ★ GitHub · Releases · ·

Claude Code,
Without The
Blast Radius.

DevCell is a local-first sandbox for AI coding agents. Run Claude Code, Codex, OpenCode, or Gemini inside an isolated cell. Agents write, delete, and install freely. Your host is untouched.

No account. No API key with Max/Pro. brew install and go.

"Run this in a container, not your actual machine."
— Anthropic, Claude Code documentation

View on GitHub → Quickstart

Works with

~/myproject $ devcell claude

Opening cell myproject …

✔ mounted /home/alex/myproject

✔ ~/.ssh, ~/.aws: not mounted

───────────────────────────────────────

  Claude Code
· Opus 4.6 · Claude Max
  /myproject

───────────────────────────────────────

❯ implement login form

───────────────────────────────────────

⏵⏵ auto-approve · [*.] Cell Active

Getting started

Quickstart

1

Install

brew install devcell-sh/tap/devcell. Requires docker.
Platforms: macOS, Linux.
2

Run from any project

cd my-project && devcell claude. First run scaffolds config and builds. Works with devcell codex, devcell opencode, and devcell gemini too. Claude Max, Pro, and API keys all work — it's the client you already use, inside the cell.

    
# macOS & Linuxbrew install devcell-sh/tap/devcell# run from any project directorycd ~/dev/my-projectdevcell claude

Features

What you get.

Container sandbox

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.

Egress lockdown

devcell claude --solitary denies all outbound traffic except allow-listed domains. The agent cannot phone home, push to the wrong remote, or exfiltrate tokens.

No account, no login

brew install devcell-sh/tap/devcell, cd your-project, devcell claude. No Docker Hub login, no cloud dashboard, no API key required with Claude Max/Pro.

MCP servers with backing tools

You don't install MCP servers; they come ready. 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. 11 servers, each pinned to a commit hash.

Three OS engines

Linux container (Docker), macOS VM (Tart), Windows VM (winkit)^e. Same commands, same config. Pick the guest with --os and the engine follows.

Your config carries over

CLAUDE.md, hooks, skills, and MCP config mount into the cell. Your project-level setup works unchanged. 1Password secrets inject at runtime on a RAM-only tmpfs, gone when the cell stops.

Project The agent sees the project dir it was launched in. Other repos aren't hidden, they're absent.

Cell Its own home: dotfiles, shell history, agent memory. Shared across that cell's projects, invisible to other cells.

Host Nothing outside the mount and the cell home. ~/.ssh, ~/.aws, your real home: unreachable.

Docker by default. When your threat model demands a real kernel boundary, --engine tart runs the same cell in a VM.

DevCell starts and controls

One CLI. Three environments.

Linux

Docker container. Zero config. Starts in seconds.

devcell claude

macOS

Tart VM. Full macOS guest.

devcell claude --os macos

Windows^e

QEMU Windows VM with WSL inside.

devcell claude --os windows

Same commands, same config, same toolchain. DevCell provisions the environment, mounts your project, and launches the agent. Pick the guest with --os.

Comparison

How it compares.

	DevCell	Docker Sandboxes	Daytona	Microsandbox	Raw docker run
Host isolation	container, VM	microVM	container	libkrun	manual
Account / login required	no	yes	yes	no	no
Claude Max/Pro (no API key)	yes	documented, broken	no	no	manual
CLAUDE.md + hooks preserved	yes	no	no	no	manual
MCP servers + backing tools	yes, auto-config	catalog (manual)	no	own MCP	manual
macOS + Windows VMs^e	yes	no	no	no	no
Egress lockdown	yes	yes	yes	yes	manual
Local-first	yes	yes	cloud only	yes	yes
Credential brokering	not yet	yes (proxy)	yes (API)	yes	manual
Snapshot / restore	not yet	not yet	yes	yes	no

Use Docker Sandboxes for microVM isolation. Use Daytona 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.

What's inside

Focused stacks, not a kitchen sink.

Every cell anchors to one devcell.toml. Each stack ships only what its MCP servers need — Playwright cells have Chromium, IaC cells have OpenTofu, GUI cells have a display server. Start with base (~1.3 GB), adopt more when the work needs it.

First run scaffolds devcell.toml and builds the default stack. Change it anytime in the config, and the agent can install whatever else the project needs.

Everything in the image is defined in devcell-sh/home — read it, fork it, or reuse the modules standalone. Drop a .tool-versions for runtime versions, extend a stack with nix overlays. Upstream updates still merge cleanly.

Compare the stacks →

	base	ultimate	bbb	electronics
Dev essentials	✓	✓	✓	✓
Go + Node + Python	—	✓	✓	—
Infra tools	—	✓	✓	—
Browser + sessions	—	✓^*	✓^*	—
GUI desktop	—	✓	✓	✓
Security / RE	—	—	✓	—
Electronics	—	—	—	✓
11 MCP servers with backing tools	—	✓	✓	✓

^* Headless only. GUI desktop (VNC/RDP) ships in the ultimate stack; other stacks add it via modules.

Need a different mix? Set stack and modules in devcell.toml. Multi-arch (amd64/arm64), published to ghcr.io/devcell-sh/devcell.

Common questions

FAQ

Do I need an API key or Claude subscription?

Bring your own license or model. Claude Max, Pro, and API keys all work — DevCell starts the same client you already use, just inside a container. Same goes for Codex, OpenCode, and Gemini.
Why not just write my own Dockerfile?

You can — the afternoon is the demo; the maintenance is the product. A hand-rolled container needs MCP wiring, backing apps, a display server, secrets handling, UID mapping, and per-agent flags — and needs them again after every client update. Everything DevCell ships is defined in the open devcell-sh/home modules: read them, fork them, or reuse them standalone if you'd rather keep your own setup.
How is DevCell different from Docker Sandboxes?

Docker Sandboxes use microVMs for stronger isolation and integrate with the Docker ecosystem. DevCell is local-first with no account required, preserves your CLAUDE.md and hooks, ships MCP servers with their backing tools pre-installed, and supports macOS and Windows VMs^e. Docker Sandboxes require a Docker account and drop your Claude config.
Can the agent install packages inside the container?

Yes. The agent can run apt, npm install, pip install, nix — whatever the project needs. Network access is unrestricted by default. devcell claude --solitary locks down egress to allow-listed domains only. Port forwarding and extra volume mounts are configurable in devcell.toml.
Does my existing Claude Code config carry over?

Your project-level config (CLAUDE.md, .claude/) is mounted with your project. Host ~/.claude/skills is mounted read-write, the rest of ~/.claude is read-only. Your host-machine config stays safe.
How big are the images? Can I skip Docker?

Base is ~1.3 GB and builds in under 2 minutes; ultimate is ~20 GB. First run builds the default stack. No Docker? --os macos provisions the same cell as a VM (tart, Apple Silicon) — same toolchain, same commands.

Claude Code,Without TheBlast Radius.

Quickstart

Install

Run from any project

What you get.

Container sandbox

Egress lockdown

No account, no login

MCP servers with backing tools

Three OS engines

Your config carries over

One CLI. Three environments.

Linux

macOS

Windowse

How it compares.

Focused stacks, not a kitchen sink.

FAQ

Claude Code,
Without The
Blast Radius.

Windows^e