--- title: "Claude Code on Fly.io Sprites: give Claude a computer of its own" description: "Run Claude Code inside a Sprite, a Firecracker microVM with its own kernel, persistent disk and checkpoints, or install the Sprites plugin for Claude Code." --- # Give Claude Code a computer of its own. Sprites for Claude Code: a plugin for your terminal, and a microVM to run it in. Install the plugin Run Claude on a Sprite Claude Code only really starts to feel like cheating when you don't have to spend your days hovering over the approve button. That's why your laptop isn't the right place to run it. Every command Claude runs, runs as you, right next to your SSH keys, your cloud credentials and every other repo you own. So give it a computer of its own. A Sprite is a Firecracker microVM with its own kernel and a disk that stays put. Simply install the Sprites Claude Code plugin and your Claude has everything it needs to build, test and serve on a Sprite. Want to work with Claude Code from inside the Sprite? Even easier. It's already installed and the whole session stays inside the box. Create a Sprite, type claude and go! Two ways in ## Pick where Claude runs - The plugin **Run Claude anywhere and have it do its work in a Sprite.** The plugin connects Claude Code to the Sprites hosted MCP server at `sprites.dev/mcp`. Claude can create Sprites, run commands in them, start services, read logs, take checkpoints and manage network policy, all as tool calls. Claude itself, and the files it edits locally, stay on your machine. What moves is the part that runs code: the install, the build, the tests, the server. This is the one to use when you want to keep your local setup and stop letting dependency-heavy or risky commands run next to your keys. Install the plugin - Inside the Sprite **Run Claude inside the Sprite.** Every Sprite comes with Claude Code pre-installed. Open a shell, run `claude`, and the whole session happens in the microVM: file tools, hooks, MCP servers and every shell command. This is the one for unattended work, for `--dangerously-skip-permissions`, and for repositories you don't trust. Run Claude Code on the Sprite Quickstart: the plugin ## Install the plugin No Sprites CLI needed. Inside Claude Code: 1. 1 **Add the marketplace.** `/plugin marketplace add superfly/sprites-claude-plugin` ``` /plugin marketplace add superfly/sprites-claude-plugin ``` 2. 2 **Install the plugin.** `/plugin install sprites@sprites` ``` /plugin install sprites@sprites ``` 3. 3 **Reload so Claude picks up the new tools.** `/reload-plugins` ``` /reload-plugins ``` 4. 4 **Authorize.** Run `/mcp`, pick the `sprites` server the plugin added, and finish the OAuth flow in your browser for the Fly.io organization you want. On the consent screen, keep restricted access with a name prefix such as `mcp-`. Claude can then only see and touch Sprites whose names start with that prefix, and you can cap how many it creates. Full access removes the prefix and hands Claude every Sprite in the organization. 5. 5 **Check it works.** `/sprites:status` ``` /sprites:status ``` An empty list means you're authenticated and working. `/sprites:smoke` goes further: it lists, creates a Sprite, runs a command in it, and asks before cleaning up. ### Now give it something real. Tell Claude: Create a Sprite, clone github.com/you/your-app into it, install the dependencies and run the test suite. Tell me what fails. **Important:** your local checkout is not the Sprite's filesystem. Claude clones into the Sprite rather than uploading your working tree, so push the branch you want it to work on first. Quickstart: Claude in the Sprite ## Run Claude Code on the Sprite 1. 1 **Install the Sprites CLI and sign in.** `curl https://sprites.dev/install.sh | bash` ``` curl https://sprites.dev/install.sh | bash ``` `sprite login` ``` sprite login ``` 2. 2 **Create a Sprite and open a shell on it.** `sprite create my-app` ``` sprite create my-app ``` `sprite console -s my-app` ``` sprite console -s my-app ``` 3. 3 **Start Claude.** `claude` ``` claude ``` Sign in when it asks, clone your repo, and work the way you would locally. The Sprite runs as a non-root `sprite` user with passwordless sudo, so Claude has full control of the machine and `--dangerously-skip-permissions` starts (Claude Code refuses that flag as root). To leave it working, detach with Ctrl+\ and close your laptop. A Sprite stays awake while it has an active session, so Claude keeps going. `sprite attach` puts you back in front of it. Why a Sprite ## What Claude gets, and what it can't reach 1. **Your credentials aren't on the machine.** Claude reads what's in the repo, and so does anything that can write to the repo: a dependency with a postinstall hook, or a README with instructions aimed at an agent. On your laptop, whatever that code runs can open `~/.ssh` and `~/.aws`. In a Sprite, those files don't exist. The environment Claude runs in is built explicitly at boot, so nothing from the host leaks into it, and the only secrets on the box are the ones you put there. 2. **You decide where it can connect, from outside.** Give a Sprite a network policy and every outbound connection not on the allowlist is dropped at the packet level, including code that skips DNS and dials an IP directly. Code inside the Sprite can read its policy and can't change it, so a prompt-injected Claude can't widen it either. Egress is open by default, so for untrusted work, set the allowlist before you start. 3. **The disk is still there tomorrow.** A Sprite has a persistent ext4 filesystem. The cloned repo, the installed dependencies, your `CLAUDE.md`, and Claude's own session history under `~/.claude` are all where you left them, so `claude --continue` picks the conversation back up. An idle Sprite sleeps and costs no compute while it does, and the next command wakes it. One Sprite per project, and none of them see each other's dependencies. 4. **When Claude wrecks it, roll back.** A checkpoint is a copy-on-write snapshot of the whole filesystem: packages, databases, config. `sprite checkpoint create` before the risky thing, `sprite restore` after it goes wrong, as many times as you need. The plugin prompts Claude to checkpoint before risky installs, migrations and broad destructive commands, and asks you before it destroys a Sprite, restores a checkpoint or replaces a network policy. 5. **It can show you what it built.** A service is a long-running process that the Sprite restarts if it crashes and relaunches after a reboot. Every Sprite has an HTTPS URL with automatic TLS, and a service with an HTTP port answers on it, so Claude can start the app and hand you a link. The URL requires Sprites auth unless you make it public, and none of the plugin's tools can make it public. ## Frequently asked questions Do I need the Sprites CLI to use the Claude Code plugin? + No. The plugin connects Claude Code to the hosted Fly.io Sprites MCP server and authenticates with browser OAuth, so the CLI never enters into it. You need the Sprites CLI only if you want to open a shell on a Sprite yourself, which is how you run Claude Code inside one. Does the Sprites plugin run Claude Code inside the Sprite? + No. With the plugin, Claude Code keeps running on your machine and uses Fly.io Sprites as remote computers: it creates them, runs commands and services in them, and reads their logs over MCP. Claude's own file edits happen locally. To put the whole Claude Code process inside the microVM, run claude on the Sprite instead. Is Claude Code already installed on a Sprite? + Yes. Every new Sprite on Fly.io comes with Claude Code preinstalled, along with other coding agents and runtimes including Node.js, Python, Go, Ruby and Rust. Open a shell with sprite console and run claude. Is it safe to run Claude Code with --dangerously-skip-permissions on a Sprite? + Yes, that is what a Sprite is for. The whole Claude Code process runs inside a Firecracker microVM with its own kernel, as a non-root user, on a machine that holds none of your local credentials. Set a network policy first if the repository is untrusted, since Fly.io leaves egress open until you do, and checkpoint before a long unattended run so you can restore it. Which Sprites can Claude reach through the plugin? + The ones you allow when you authorize it. With restricted access, the Fly.io OAuth grant limits Claude to Sprites whose names start with a prefix such as mcp-, and it can cap how many Claude creates. Full access grants every Sprite in the organization, so choose it only when you mean to. Does Claude Code keep running on a Sprite after I close my laptop? + Yes. Detach from the session with Ctrl+\ and the process keeps running on Fly.io, because a Sprite stays awake while it has an active session. Reconnect later with sprite attach. Once nothing is running and nothing is connecting, the Sprite sleeps with its disk intact. How do I stop Claude from reaching the whole internet from a Sprite? + Set a network policy. Fly.io drops every outbound connection that isn't on the Sprite's allowlist, at the packet level, and code inside the Sprite can read the policy but not change it. Egress is open by default, so set the policy before you point Claude at untrusted code. What happens if Claude breaks the Sprite? + Restore a checkpoint. A Sprite checkpoint on Fly.io snapshots the entire filesystem, including installed packages and databases, and sprite restore puts it back as many times as you need. With the plugin installed, Claude is prompted to checkpoint before risky installs and migrations, and asks you before any restore. Can I preview the app Claude builds on a Sprite? + Yes. Run the app as a service with an HTTP port and it answers on the Sprite's own HTTPS URL, with TLS handled by Fly.io. The URL requires Sprites authentication by default, so the preview isn't public until you make it so. Does Sprites work with Claude Managed Agents? + Yes, as a separate integration. Anthropic runs the agent loop and the model, and the agent's tools execute in Sprites you run on Fly.io, one per session. The Claude Managed Agents guide at docs.sprites.dev/integrations/claude-managed-agents covers the setup.