Give Your Own Claude Desktop, Codex, or Cursor a Real Sandbox

The bash tool built into your IDE or CLI coding agent runs exactly where you'd expect it to: on your own machine, with your own filesystem, your own network, your own credentials in scope. That's fine right up until the snippet it's executing came from a dependency, a web search result, or a repo you don't fully trust — at which point "runs on my laptop" stops being a convenience and starts being the thing you're worried about.

The problem with a sandbox that's just your own machine

Claude Desktop, Claude Code, Codex, and Cursor all give their agent a way to run shell commands, and by default that's a direct line to your actual environment. Most of the time that's exactly what you want — a coding agent that can't touch your machine isn't very useful. The gap shows up specifically around untrusted input: a snippet the agent pulls from somewhere you don't control, then executes without you reading it first.

boxkite's own README is upfront that it isn't built for this exact scenario out of the box — it explicitly calls out that if you just want your own coding assistant to run shell commands on your own machine, boxkite's multi-tenant, cluster-operated sandbox is the wrong layer. That's true for the library. It stops being true the moment you self-host it and point your own assistant at it.

What boxkite-mcp actually exposes

The boxkite-mcppackage wraps boxkite's tool surface as an MCP tool source, and it can be exposed over a remote Streamable-HTTP endpoint rather than only as a local process. Claude Desktop, Claude Code, Codex, and Cursor all speak MCP as clients — so instead of your assistant's bash tool executing directly against your laptop, it calls out over MCP to a server you control, and that server is the one actually running the code.

Where the code actually runs

This is a self-hosting story, not a hosted-product one: boxkite is open source under the MIT license, and running it yourself means the pod your assistant's commands execute in lives on infrastructure you operate — a home cluster, a small cloud VM running a single-node Kubernetes distribution, or whatever you already run for other self-hosted tools. Nobody's laptop, and no third party's multi-tenant service, is in the loop.

Why network-dark-by-default is the load-bearing property here

The specific risk this closes is exfiltration and lateral movement. A snippet that turns out to be malicious — or an agent that gets steered into running something it shouldn't by content it read rather than content you wrote — is still executing somewhere. What it can't do, because the pod has no network access unless you've deliberately widened it, is reach out to your home network, your other machines, or an attacker-controlled endpoint on the open internet. It runs, and whatever it does stays inside the pod until you look at the result.

Walking the tool surface

For this use case the tools that matter are the same ones any coding assistant already reaches for: bash_tool to actually run the snippet, python_interpreter when the untrusted code is Python and you want a persistent interpreter rather than a fresh process per call, and view, str_replace, ls, glob, and grepfor actually inspecting and working with whatever the execution produced, rather than taking the sandbox's word for it. None of this requires the opt-in git or node tool sets unless your own workflow needs them.

When this is worth doing

This is a cluster-of-one version of the same argument multi-tenant platform teams make at much larger scale: isolation as a structural property of where code runs, not a policy you have to trust the agent to respect. For a solo developer, the honest trade is operational — you take on running a small Kubernetes setup in exchange for a coding assistant that can execute genuinely untrusted code without that code ever touching your actual laptop or your home network.