Support Sandboxing

[dwt]

Description

HI there,

I would very much like to give the agent more independence with command execution, but cannot do so without more restrictions to what it can do.

Sandboxing the agent is a way forward that would allow this, bubblewrap (linux) and seatbelt (darwin) can support this and do not require to run inside a docker container (which still cannot sandbox network access, which is a big problem).

Would you be up for that?

If you want to go down that implementation route, I really like https://github.com/anthropic-experimental/sandbox-runtime to unify sandboxing on linux and darwin, which could greatly help getting this up and running much faster.

[meowgorithm]

Hey! Thanks for filing this. This is definitely a real concern and important topic. I'm going to convert it to a discussion (for further discussion). If we can agree on a plan, and whether this should be in Crush, we can convert back to an issue for implementation.

[jy-tan]

I needed this capability in my own projects so I recently created a Go implementation of sandbox-runtime, called fence (https://github.com/Use-Tusk/fence). Would be happy to see if this works with Crush.

[smoyer64]

I have a wrapper that creates a new git worktree and then uses bubblewrap to only allow crush to mutate files inside the sandbox - It's so nice knowing that the worst that can happen is that the worktree is trashed!

[cedws]

Anybody know an agent that has proper, built in sandboxing? Claude Code's sandboxing is a joke and I'm not really enjoying the explosion of third party sandboxing tools just so you can have some basic assurance that your home directory isn't going to get nuked or uploaded to a C2 server.

[dwt]

Claude Codes sandboxing is the best I currently know of.

Depending on your sandboxing needs, you might want to additionally sandbox it with kernel namespaces (aka Podman Container) or even further with a virtual machine to reduce the attack surface of your environment at the cost of convenience.

[jy-tan]

@meowgorithm 👋 Following up on this since it's been a while - Fence is a lot more mature now than when I first mentioned it here, and fence -t code -- crush is working for me as a wrapper.

That's made me think there's probably a pretty practical path for deeper integration inside Crush and make process sandboxing a first-class feature in Crush. The main motivation would be to complement Crush's existing permission prompts with actual OS-level containment for the agent's shell commands / background jobs (network, filesystem, command restrictions), while keeping the UX closer to native Crush than an external wrapper. My guess is this would be especially useful for people who want to give Crush a bit more freedom while still keeping a real containment boundary around shell execution.

I think the first cut can stay intentionally small: shell-level only, centered on Crush's existing bash/internal shell execution path and background jobs, not every tool/process in Crush. So built-in ls / grep / glob, MCP, LSP, etc. can stay out of scope for v1. For users who aren't already Fence users, zero-config could just default to Fence's code base; if a repo/user fence.json already exists, Crush can use that as the base instead.

If this direction sounds interesting, happy to flesh out the design and concrete implementation details in a separate issue or PR.

[harmw]

can't it (fence) just lock everything down to just the current working dir ./? That way any file operation is limited to the current directory (chroot, sort of, afaik the part bubblewrap and whatever-its-called-on-macos take care of), so no risk of thrashing ~/homework by agent mistake.
Child processes spawned are also limited to the chroot and uid of crush so I'm guessing that's solid - right?

And to shield just git operations in the current dir workspaces might be a decent solution (though I lack familiarity with that to be able to make suggestions on it).

Networking could probably default to just block everything (at start), maybe have an exception for configured MCP endpoints.

Could start simple with a flag to disable the fence, just a simple crush --no-fence.

On a side note: what does the current security model of crush look like (imho a good topic for the README)? Does it just gatekeep the tool calls coming from the model?

[dwt]

can't it (fence) just lock everything down to just the current working dir ./?

You could easily, but most sandboxes this strict are not useful anymore to the agent to actually get work done. Tools like git need access to the configuration in your home directory to just get who you want to commit as for example.

That being said, they need read access to those config files, not write access. Still useful sandboxing is a little bit of a fine tradeoff between enough blocking to remain as secure as possible while not blocking too much so you still can get work done by your agent.

And to shield just git operations in the current dir workspaces might be a decent solution (though I lack familiarity with that to be able to make suggestions on it).

Right now the domains sandboxed processes are allowed to talk to are fairly limited (check fence config show --template code for example to get an overview what it configures.

Networking could probably default to just block everything (at start), maybe have an exception for configured MCP endpoints.

This depends. Most coding agents need to talk to one cloud ai provider or another. That being said - if you have a local model, there's nothing stoping you from creating a sandbox that locks it down until you are satisfied.

I think this is the entire point of fence you can see, inspect and tune it's sandbox easily, because all of that is the main point of the tool and therefore documented and relatively easy to inspect and adapt. Anything built into your coding agent is quite probably far harder to debug, inspect and adapt.

Could start simple with a flag to disable the fence, just a simple crush --no-fence.

Right now it is fence crush - and disabling it would be crush. Very explicit, immediately visible and no changes to crush required. Further integration of course is possible and quite probably useful - but nothing we have right now.

On a side note: what does the current security model of crush look like (imho a good topic for the README)? Does it just gatekeep the tool calls coming from the model?

As far as I know the only security model crush has is 'the user is responsible to only allow those tool calls he inspected and is sure will cause no harm'. AKA: You are responsible, not crush.

[smlx]

In case it is useful for others, I use a wrapper script around systemd-run to sandbox crush. systemd-run has basically all the sandboxing features I need and comes built-in to most Linux desktops.