Agent Workspace · Open Source · Apache 2.0 · ★ Star on GitHub · Releases
Your Agent
Gets Its Own
Computer.
Auto-approve everything. The agent works inside a cell — a container or VM
with its own home, tools, and desktop. Your SSH keys, other repos, and
credentials aren't hidden from it; they're absent.
And inside, it has more than your machine ever gave it: real tools behind
its MCP servers, a browser with your sessions, a screen it can see.
Claude Code · Sonnet 4.6 · Claude Max /myproject
The payoff
What the agent gains inside.
Built-in sandboxes subtract tools to make agents safe. devcell adds tools and stays safe.
Tools behind the MCP servers
Marketplaces install the config. devcell installs the app underneath. OpenTofu actually runs tofu plan, Inkscape actually edits the SVG — display server included. 12 servers today, each with its backing software in the image.
A desktop it can see
VNC and RDP built in. The agent opens GUI apps, clicks through what it built, and you watch live — or take over at a login screen. Linux by default; VM engines for macOS.
Your sessions, not your browser
Run cell login <site> on your host: a real browser opens, you log in, it closes. Only that site's session crosses into the cell. The agent never sees your password — and never touches your real browser's history, cache, or other logins.
The boundary
What it can't touch.
"Run this in a container, not your actual machine."
— Anthropic, Claude Code documentation
Absent, not hidden
SSH keys, other repos, host credentials — the agent can't reach them because they aren't there. It can trash its whole machine and lose nothing but the cell: rebuild in minutes. Your project is the one live mount, same as any agent setup.
Secrets in RAM only
1Password secrets resolve on the host and land on a RAM-only tmpfs at /run/secrets/. Container stops, they're gone. The LLM never sees credential values — MCP tools resolve placeholder names server-side.
One cell per client
Named cells keep engagements apart: Acme's cell has Acme's keys, shell history, and agent memory; BigCorp's has BigCorp's. Same toolchain everywhere — add a project, inherit the setup, duplicate nothing.
~/.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.
Getting started
Quickstart
- 1
Install
brew install DimmKirr/tap/devcell. Requiresdocker.
Platforms: macOS, Linux, Windows(not verified yet) - 2
Run from any project
cd my-project && cell claude. First run picks a stack, scaffolds config, and builds. Works withcell codexandcell opencodetoo. Claude Max, Pro, and API keys all work — it's the client you already use, inside the cell.
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 asks one question — which stack. Enter takes the default; change it anytime
in devcell.toml, and the agent can install whatever else the project needs.
Everything in the image is defined in nixhome —
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 six stacks →
* 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 public.ecr.aws/w1l3v2k8/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 and OpenCode.
-
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 nixhome modules: read them, fork them, or reuse them standalone if you'd rather keep your own setup.
-
How is DevCell different from Dev Containers?
Dev Containers are editor-first — a Dockerfile + devcontainer.json per project for VS Code or Codespaces. DevCell is agent-first: one command, pre-built Nix-pinned stacks shared across projects, MCP servers with their backing tools in the image, VNC/RDP built in, secrets on tmpfs. No per-project Dockerfile drifting apart.
-
How is DevCell different from OpenClaw?
Different layers. OpenClaw is an assistant framework; devcell is the contained machine an agent runs on. They compose: run OpenClaw inside a cell and its skills keep working while your SSH keys and credentials stay out of reach.
-
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. 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. (Subject to change.)
-
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 lets you pick a stack. No Docker? --os macos provisions the same cell as a VM (tart, Apple Silicon) — same toolchain, same commands.
Get started
Ready to try it?
One command. One question on first run. Enter takes the default.
