Codex works better with a computer it can break.

Sprites for Codex: a plugin for the CLI you already run, and a microVM to run it in.

Codex is OpenAI's super popular coding agent, tool of choice for a huge segment of the agentic coding community. With a giant and ever-growing menu of plugins and extensions, there's not a whole lot you can't accomplish with Codex these days, but it really shines when you can give it something to do and come back when its done. To get that kind of Codex experience, you need to be running it in the right environment and your laptop isn't it.

Codex does ship with its own sandbox. Out of the box it can edit files in your project and run commands there, and it stops to ask you before it reaches any further. But that boundary is drawn around a process on your own machine, so it gets more flimsy as you try to get Codex to work with fewer interruptions. Turning approvals off is just ... a really bad idea.

Codex can live up to its full potential in a Sprite though. A full Linux machine on a Firecracker microVM, with its own kernel and a disk that stays put. Install the Sprites plugin and run Codex from wherever you want, with all its builds, tests and services running on a Sprite instead of your machine. Or run Codex inside a Sprite. It comes preinstalled, so just run codex from the Sprite console and you're working in a whole environment you can checkpoint and rebuild whenever Codex breaks something.

Two ways in

Pick where Codex runs

  • The plugin

    Keep Codex local, put the work on a Sprite.

    The Sprite plugin connects Codex to the Sprites MCP server at sprites.dev/mcp. From there, Codex can create a Sprite, run commands in it, start services, read the logs those services write, take a checkpoint before it does anything risky, and tighten the network policy. Codex itself still runs on your machine, there's just no more dependency installs, builds, test runs or dev servers running on your laptop.

    Install the plugin

  • Inside the Sprite

    Run Codex inside the Sprite.

    Every Sprite comes with Codex pre-installed. Open a shell, run codex, and the whole session happens in the Sprite. This is where danger-full-access can be your new default, because the machine it has full access to holds nothing of yours except the repo you cloned into it.

    Run Codex on the Sprite

Quickstart: the plugin

Install the plugin

No Sprites CLI needed.

  1. 1

    Install the Sprites plugin from the Codex plugin marketplace.

    Codex distributes it through its own marketplace, so there is no install one-liner to copy.

  2. 2

    Or add this repository as a marketplace, from a local checkout.

    codex plugin marketplace add .

    Then restart Codex, open the plugin directory, choose the Sprites marketplace, and install Sprites.

  3. 3

    Authorize when Codex asks.

    The plugin registers the hosted MCP server, and Codex runs the OAuth flow the first time it calls a Sprites tool. Pick the Fly.io organization you want.

  4. 4

    Check it works. Ask Codex:

    List my sprites.

    An empty list is a successful, authenticated answer.

Then give it something real:

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. Codex clones into the Sprite rather than uploading your working tree, so push the branch you want it to work on first.

If Codex ever offers to run codex mcp add sprites to fix missing tools, say no. That registers a second, unmanaged server. Restart Codex or reinstall the plugin instead.

Quickstart: Codex in the Sprite

Run Codex on the Sprite

  1. 1

    Install the Sprites CLI and sign in.

    curl https://sprites.dev/install.sh | bash
    sprite login
  2. 2

    Create a Sprite and open a shell on it.

    sprite create my-app
    sprite console -s my-app
  3. 3

    Start Codex.

    codex

    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 Codex can install what it needs and own the machine while it does.

To leave it working, detach with Ctrl+\ and close your laptop. A Sprite stays awake while it has an active session, so Codex keeps going. sprite attach puts you back in front of it.

Why a Sprite

What Codex gets, and what it can't reach

  1. Your credentials aren't on the machine.

    Codex reads what is in the repo, and so does anything that can write to the repo: a dependency with a postinstall hook, or an AGENTS.md carrying instructions aimed at an agent. On your laptop, the blast radius of a command that gets past the sandbox is your SSH keys, your cloud credentials and every other repo you own. In a Sprite, none of those files exist. The environment 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, and 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. The policy is set from outside the Sprite. Code inside can read it and has no way to widen it, so a prompt-injected Codex cannot open the door it is standing behind. Egress is open until you set a policy, so set it before you point Codex at code you don't trust.

  3. The disk is still there tomorrow.

    A Sprite has a persistent ext4 filesystem, so nothing has to be rebuilt for the next session. The repo Codex cloned is still checked out, the dependencies it spent ten minutes installing are still installed, and your AGENTS.md is still telling it how you work. Its own transcripts sit under ~/.codex/sessions on that disk too, so codex resume --last picks the conversation back up where it stopped. 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 toolchains.

  4. When Codex wrecks it, roll back.

    A checkpoint is a copy-on-write snapshot of the entire filesystem, so it captures the packages Codex installed and the databases it seeded along with your files. Take one before the risky thing and restore it afterwards, as many times as you need. The plugin's guidance has Codex checkpoint before destructive work, and destroying a Sprite only happens when you ask for it by name.

  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 Codex can start the app and hand you a link. The URL requires Sprites auth until you make it public, so treat anything a service serves as reachable by whoever you share it with.

Frequently asked questions

Do I need the Sprites CLI to use the Codex plugin? +

No. The plugin connects Codex to the hosted Fly.io Sprites MCP server and authenticates through Codex's own plugin flow, 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 Codex inside one.

How do I install the Sprites plugin for Codex? +

Install Sprites from the Codex plugin marketplace, which is where Fly.io publishes it, then authorize it for your Fly.io organization when Codex prompts you. You can also run it from a local checkout: use codex plugin marketplace add . inside the repository, restart Codex, and install Sprites from the plugin directory.

Does the Sprites plugin run Codex inside the Sprite? +

No. With the plugin, Codex 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. Your local workspace stays separate from the Sprite's filesystem. To put the whole Codex process inside the microVM, run codex on the Sprite instead.

Is Codex already installed on a Sprite? +

Yes. Every new Sprite on Fly.io comes with Codex preinstalled, along with other coding agents and runtimes including Node.js, Python, Go, Ruby and Rust. Open a shell with sprite console and run codex.

Can I run Codex with danger-full-access on a Sprite? +

Yes, and a Sprite is the right place for it. Full access removes Codex's filesystem and network boundaries, so what matters is the machine underneath: on Fly.io that is a Firecracker microVM with its own kernel, holding none of your local credentials. Set a network policy first if the repository is untrusted, and take a checkpoint before a long unattended run.

Why use a Sprite when Codex already has a sandbox? +

Because they answer different questions. Codex's sandbox decides what a command is allowed to touch on whichever machine it runs on. A Fly.io Sprite changes which machine that is, to a microVM with its own kernel, its own disk and none of your keys on it. The two stack: run Codex in its sandbox, inside a Sprite, and a command that gets past the first boundary still lands somewhere you can throw away.

Does Codex 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 Codex 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 Codex at untrusted code.

What happens if Codex breaks the Sprite? +

Restore a checkpoint. A Sprite checkpoint on Fly.io snapshots the entire filesystem, including installed packages and databases, and restoring puts it back as many times as you need. The plugin's guidance has Codex take a checkpoint before destructive work, and it destroys a Sprite only when you ask for that Sprite by name.

Can I preview the app Codex 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.