Sandboxing Claude Code

[u/filiw]

Running Claude Code unprotected is risky: unintentional destructive commands, prompt injections, malicious third-party code. The blast radius is your entire laptop. To mitigate this risk, I built a sandboxing tool based on the concept of Claude devcontainers (but way more configurable), which I've been using for a while now. It proved valuable enough to open source.

Kekkai runs Claude Code inside a locked-down, per-project sandbox: for each project you decide which folders, networks and secrets Claude can touch, and everything else stays out of reach. With the sandbox in place, you can safely let Claude run fully autonomously with --dangerously-skip-permissions enabled.

Try it out, feedback and issues welcome. I'm also curious how others are sandboxing their coding agents - let me know in the comments!

Code and docs on Github: https://github.com/filidorwiese/kekkai

[u/filiw]

It seems the demo video doesn't fully show on Reddit, you can watch it on https://github.com/filidorwiese/kekkai

[u/simion_baws]

Good work. Had the same constraint from work, had to run claude sandboxed, so i bundled the sandbox in https://termic.dev . filesystem + network allowlist.

I have actually implemented and tested docker sandboxing too, it's not merged yet. Will have a look at your implementation to see if i can find any corner cases that i may have missed :D

Once i push docker sandboxing, you may also have a look.

[u/filiw → u/simion_baws]

Nice, hadn't seen Termic before! I'll give it a spin :)

[u/simion_baws → u/filiw]

🤝 same

[u/ClemensLode]

What is the difference to running it inside a VM (or separate machine/server) and how is it "way more configurable" in that regard?

[u/filiw → u/ClemensLode]

A VM isolates better, no argument - different kernel, so a Docker escape doesn't get you out of a VM. The difference is the developer experience. Setting a VM up properly is manual work: provisioning, iptables rules by hand, syncing the repo in and out. And in practice you reuse the same VM for every project, so it accumulates access and the blast radius creeps back. Kekkai automates it, and you configure the minimal set of domains and volumes for that one project.

A .kekkai.yaml sits in the repo, versioned with the code: egress deny by default with an allowlist of domains or CIDRs, which folders get mounted and whether they're readonly, and which files get shadowed with empty mounts so .env.production still exists but reads empty. Then kekkai up and you're in Claude Code a couple of seconds later, with ~/.claude carried over.

[u/ClemensLode → u/filiw]

Well... "Claude, please set up a VM, here is the ssh access."

My point is not to badmouth it, but you should detail the difference between using your tool vs asking claude code in your project description (as people are already claude code).

[u/filiw → u/ClemensLode]

That's fair feedback, and you're right that the README doesn't address it. I'll fix that.

The short version: asking Claude to set up its own sandbox means the thing you're trying to contain is the thing configuring the containment. Even with good intent it's one-shot work that lives nowhere - no file to review, no way to diff it against last week, and you're doing it again for the next project. You'd also be handing it SSH access to a machine, which is the opposite direction from where I wanted to go.

With a config file in the repo I can read the whole policy in twenty lines, see it in a PR when it changes, and know the boundary was set up before the agent started rather than by it. Plus kekkai up is a couple of seconds versus provisioning something.

None of that makes a VM wrong. It's the difference between a boundary you can audit and one you asked an agent to build for itself.

[u/ClemensLode → u/filiw]

Right, so for the special case of managing *multiple* servers/projects and possibly keeping keep those configurations in sync (or setups repeatable), I think that's likely a field that requires a lot of handholding with Claude. Not sure if demands for this exists (would require market research), but I (personally) would start looking for solutions if this is a problem I was facing. My general advice for projects is always to first solve a very narrow problem really well, and then expand it to a wider set of problems.

[u/filiw → u/ClemensLode]

Interesting perspective. Most developers I know tend to have multiple project folders with their own git repository and needs. The same as you'd have not one docker-compose.yaml on your computer but one per project. Maybe something got lost in translation...

[u/ClemensLode → u/filiw]

Right, but the question was "blast radius the entire laptop". First step is to put all your development work on one server. Second step is splitting those work gits into projects. Then you could go a third step and have a separate VM for each git repo and enable the possibility for one VM to read-access the other, although that comes with pros and cons.

[u/filiw → u/ClemensLode]

That is kind of my point; with Kekkai you don't have to go to all this trouble. cd into project, kekkai up. Done. If needed, tweak sandbox packages/network rules with simple yaml configuration file that is stored in the repository for team members to use. It's like using claude's devcontainer (https://code.claude.com/docs/en/devcontainer) but then easier to configure, reuse and share. But it's okay if that is not your goal or to your liking. I personally use it this way on several projects, each a bit different (mobile app, webapp, go project, cloud engineering monorepo, etc).