boxes.dev
ditch localhost; run Claude Code and Codex in the cloud
Last verified:
What is boxes.dev?
Boxes.dev is a cloud-only agentic development environment (ADE) that gives every Claude Code and Codex agent its own dedicated cloud computer. Instead of running coding agents on your local laptop, Boxes.dev ports your entire local dev setup to the cloud, where each Claude Code or Codex thread starts from a snapshot of your full setup with its own isolated filesystem and compute resources.
Key features include full isolation (filesystem plus compute per thread), the ability for agents to run and test your full app end-to-end in isolation, mobile and desktop apps with persistent terminals organized by thread/machine, scheduled automations, Slack integration, and optimization for parallel agent workflows. The platform auto-handles port forwarding, so you can access localhost:3000 on your selected thread's machine. Agents can run Playwright for tests, take Chromium headless, and send screenshots to threads.
Boxes.dev is designed for software developers and teams who use coding agents like Claude Code or Codex heavily, especially those running multiple parallel agent threads. It solves problems like clunky git worktrees, resource constraints when running multiple app copies locally, laptop dependency for long-running agent tasks, and poor mobile coding experiences. The target users include solo developers wanting to push agents harder, teams building agent products, and companies needing standardized environments without engineering onboarding time.
boxes.dev pricing
Pricing model: Freemium
All new users get 10 free box-hours to test the platform. Boxes.dev uses pay-per-use pricing billed by the second with no upfront costs. The default configuration is 4 vCPU / 8 GB memory (configurable at team/project level, can go higher). Pricing is based on VM-seconds consumed - you only pay for boxes you run. There is likely a minimum monthly cost (based on early feedback mentions of pricing optimization). The platform uses E2B MicroVMs as infrastructure provider. For companies, they are exploring support for bringing your own compute and hosting in your own cloud.
boxes.dev pros
- Each Claude Code/Codex thread gets its own isolated cloud VM
- Full filesystem and compute isolation per agent thread
- Agents can run and test full app end-to-end in isolation
- No more clunky git worktrees for parallel work
- Solves resource constraints from running multiple app copies locally
- Full-featured desktop app with native UX (not remote control)
- Full-featured mobile app for coding from anywhere
- Persistent terminals organized by thread and machine
- Auto port forwarding to localhost on desktop
- Supports Playwright for testing with Chromium headless
- Agents can send screenshots visible in desktop and mobile apps
- Scheduled automations for background agent tasks
- Slack integration for team workflows
- Optimized for parallel agent workflows
- Template box snapshotted for instant thread creation
- Uses your existing Claude Code/Codex subscription
- Easy setup - agent scans local setup and ports to cloud
- No laptop needed to stay cracked open for agents
- Can run multiple agents on same repo in parallel
- Full control over Linux box in the cloud
boxes.dev cons
- EU users currently restricted from downloading the app (GDPR concerns)
- Requires internet connection - latency affects terminal use
- Cloud VMs cost money compared to free local laptop CPU
- Default box TTL is 1 hour (overrideable but still a limit)
- Soft cap of 100 active boxes per account
- Machine supply currently limited
- Dev secrets on box itself - no secure key storage with 2FA yet
- Main box continuity model not perfect for knowledge flow back from forks
- No self-hosted option yet (exploring for companies)
- Only EU regions available today
Frequently asked questions about boxes.dev
Can agents spin up Playwright for tests?
Yes, agents can run Playwright for tests. This is one of the main reasons Boxes.dev was built. Each thread/agent gets its own independent VM and filesystem, so you can run multiple copies of your app and Chromium in parallel without running out of resources like you would on a laptop. The agents can run Chromium headless and even send screenshots to the thread visible in the desktop and mobile apps.
Can I run several agents in parallel on the same repo?
Yes, this was the primary motivation for Boxes.dev. You can have multiple threads/agents running in parallel, each with its own totally independent machine. No more running out of resources locally or having to juggle git worktrees. Since there's a template/main box that gets snapshotted and cloned to produce the VM for every thread, there's no setup required per-thread or per-machine.
How does continuity work - do users spin up fresh environments or build long-lived workspaces?
Boxes.dev handles continuity with a 'main box' or template box, which is like your development laptop in the cloud. When you set up Boxes.dev, agents find your environment variables and undeclared dependencies locally, then get your app running in a cloud VM. When you create a new task, the main box is snapshotted (filesystem and RAM), and a new independent fork is created. To add context or update setup, change it on the main box and update the snapshot - all future threads get created from that snapshot.
How do you handle secrets like .dev.vars and .envrc for testing OAuth flows?
During project setup, Boxes.dev asks if you want to send your dev secret files to the cloud box - based on a local scan agents run to find which files are needed to run your app. If you say yes, those files are included in the encrypted project bundle sent to the remote machine. Right now secrets live on the box itself, and more sensitive keys like prod keys should not be uploaded or should require 2FA. They're looking into a key storage construct requiring human confirmation for access.
Does it support MCP (Model Context Protocol) and skills?
Yes, it does support MCP and skills. You get full control over a Linux box in the cloud for each Claude Code and Codex thread. It's great at running Playwright MCP and other MCP tools. If it works on your laptop via the Codex/Claude CLI, it will almost certainly work on Boxes.dev.
Can I bring my own compute or use my own VPS?
Right now Boxes.dev uses MicroVMs with E2B as the infrastructure provider. For companies, they are exploring how to support bringing your own compute. Over the long term, they'll support hosting in your own cloud. You could use VPS, but spinning up/down boxes on inactivity takes a long time, and making changes to the template is less trivial there. If only paying for 1 VPS box, you lose the 'multiple independent machines' benefit.
Will Boxes.dev support OpenCode and self-hosted/local models?
Yes, definitely. There's nothing holding them back from supporting these since the boxes are just Linux machines. They wanted to start with the most popular harnesses (Claude Code and Codex) first and go from there. The long-term vision is for the development environment to be harness and model agnostic.
How does latency affect the experience when traveling?
Over the long term, Boxes.dev will support spinning up VMs in local point-of-presence datacenters, so threads/agents you create while traveling can be colocated with you. However, even with high latency (like on a plane), the UX isn't that bad since you're just sending messages to threads and looking at screenshots from agents testing their work. Terminal use is slower with latency, but you can push the agent to do what you wanted manually in a terminal.
What's the default VM configuration and can it be changed?
The default is 4 vCPU / 8 GB memory, but it's configurable at the team/project level and can go higher. Each thread/VM is independent, so you can have multiple threads running without slowing down others. The platform uses E2B MicroVMs for infrastructure.
Do agents have access to the internet and web searches?
Right now the boxes are just Linux machines with agents running on them, so agents only have access to what you give them - typically development environment variables and keys. For web searches, since they're running a full Linux kernel and the agent runs on the machine itself, they can't sleep mid-run. The agents can run rg, bash, Playwright, and other tools on the machine itself.