Sandboxing Support

[dwt]

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.

[allen-munsch]

I've added a draft branch over here to test: cecli-dev#270

Please give it a try

It uses bubbleproc, a thing I vibed up with some opinionated defaults to patch subprocess could really use a helping hand with adding support for seatbelt, windows support.

Adding test cases, and test driving the defaulted sandboxing.

And yes it also can disable networking, etc.

bubbleproc is like an easier to use multi tool around bubblewrap, its written in rust, and has bindings tested and working bindings for python, and experimental sketches for typescript, and elixir.

There's also a cli binary which sets up a bubbleproc that can be used directly too

[congwang-mk]

+1 on the need for sandboxing. Worth considering sandlock as an option here, especially for Linux.

Sandlock uses Landlock (filesystem/network whitelisting), seccomp-bpf (syscall filtering), and user namespaces to confine processes at the kernel level. Compared to bubblewrap:

	bubblewrap	sandlock
Python API	No (CLI only)	Yes (pip install sandlock)
Filesystem isolation	Bind mounts + namespaces	Landlock path whitelisting
Network restrictions	No built-in	Domain + port allowlisting
Resource limits	No (needs cgroups)	Memory, process count, CPU, open files
Syscall filtering	No built-in	seccomp-bpf
Root required	No	No
Startup	~10ms	~20ms

For Aider's execution model, sandlock could wrap both the file editing and shell command paths:

1. File edits: restrict LLM-generated writes to only the project directory (Landlock prevents writes outside the repo)
2. /run and /test commands: execute inside a sandbox with restricted filesystem, no network (or only allowed hosts), and resource limits
3. Git operations: allow read/write to .git and the repo, block everything else

This would address the OWASP assessment findings (#4913) without requiring Docker or external services.

Disclosure: I'm the author of sandlock.

[dwt]

Since I opened this bug, https://fencesandbox.com has become available which is also a great alternative.

It allows two integrations strategies

1. Just mention it in the docs, it allows starting the agent with just fence -- $agent $agent_args
2. Deep integration (probably later) where the commands are executed in a a sandbox directly, to allow more smart command filtering options like "git operations are ok, but gut push is forbidden".