I would like to also suggest greywall[1] which i found yesterday. It sandboxes the filesystem, network, syscalls, dns. The network uses a transparent proxy to see which network requests were made. Supports linux and macos.
Go hard on agents, not on your filesystem
361–370 of 374 posts
Re: Go hard on agents, not on your filesystem
#362I'm wondering if the obvious (and stated) fact that the site was vibe-coded - detracts from the fact that this tool was hand written. > jai itself was hand implemented by a Stanford computer science professor with decades of C++ and Unix/linux experience. ( https://jai.scs.stanford.edu/faq.html#was-jai-written-by-an-... )
Human author here. The fact that I don't know web design shouldn't detract from my expertise in operating systems. I wrote the software and the man page, and those are what really matter for security. The web site is... let's say not in a million years what I would have imagined for a little CLI sandboxing tool. I literally laughed out loud when claude pooped it out, but decided to keep, in part ironically but also s…
It’s a good page!
Re: Go hard on agents, not on your filesystem
#363This looks great, like the simplicity of a chroot with some actual security.
I’m guessing it can be used to invoke individual commands from the agent harness instead of jailing the entire harness? That would enable making it much more restrictive, I think.
Re: Go hard on agents, not on your filesystem
#364Earlier quoted context omitted.
Human author here. The fact that I don't know web design shouldn't detract from my expertise in operating systems. I wrote the software and the man page, and those are what really matter for security. The web site is... let's say not in a million years what I would have imagined for a little CLI sandboxing tool. I literally laughed out loud when claude pooped it out, but decided to keep, in part ironically but also s…
It’s a good page!
A little too good...
Re: Go hard on agents, not on your filesystem
#365Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.
It will just do ssh you@localhost "rm -rf ~"
Not if the sandbox rule forbids reading the private key and the ssh agent socket (as the shown example does)
Re: Go hard on agents, not on your filesystem
#366Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.
It's common practice to ask the agent to refer to another project, in that case I guess the read should point to the root folder of the projects. Also, any details on how is this enforced? because I notice that the claude in Windows don't respect plan mode always; It has edited files in plan mode; I never faced that issue in Linux though.
The sandbox only limits what processes spawned by Claude can do. Claude itself can read from any directory you tell it to read from (i.e. that's a different permission mechanism)
Re: Go hard on agents, not on your filesystem
#367Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.
Does this also apply to the commands or programs that it runs? e.g. if it writes a script or program with a bug which affects other files, will this prevent it from deleting or overwriting them? What about if the user runs a program the agent wrote?
1. Yes this configuration applies to the sandbox where the commands executed by Claude are run and as such it applies to anything these commands do, including child processes etc
2. The sandbox rules also apply to the program written by the agent IF you ask Claude to run that program. If you run it manually from another she'll or via the "!" directive from within Claude, the sandbox won't be used
Re: Go hard on agents, not on your filesystem
#368Earlier quoted context omitted.
I have a pretty insane thing where I patched the screen sharing binary and hand rolled a dummy MDN so I can have multiple profiles logged in at once on my Mac Studio. Then have screen share of diff profiles in diff "windows". Was for some ML data gathering / CV training. It's pretty neat, screen sharing app is extremely high quality these days, I can barely notice a diff unless watching video. Almost feels like Firef…
> I have a pretty insane thing where I patched the screen sharing binary and hand rolled a dummy MDN so I can have multiple profiles logged in at once on my Mac Studio I have a Studio collecting dust that I've been eyeing every time my VM crashed because of Apple's paravirtualized GPU proxy not being able to keep up with things I run in it. This sounds exactly like what I wanted to do on my Studio and didn't know whe…
Nah but I'd be happy to share it with you over DM! (If they have DMs on here?)
Re: Go hard on agents, not on your filesystem
#369Earlier quoted context omitted.
I really like lima too. It's my go-to recommendation for light VMs. But I do consider it slightly less convenient. A good example of why is project-local .venv/ directories, which are the default with uv. With Lima, what happens is that macOS package builds get mounted into a Linux system, with potential incompatibility issues. Run uv sync inside the VM and now things are invalid on the macOS side. I wasn't able to f…
So your shared .venv is the vector for the agent to escape the sandbox.
Haha true. I’d considered that. But then, so is any code the agent writes, which will ultimately run outside the sandbox.
So it’s certainly not perfect. An isolated VM or a VPS provides the best guarantees. For me though it’s good enough. I’ve put my risk profile at: ‘don’t fuck up my system directly and don’t exfiltrate secrets directly’
Re: Go hard on agents, not on your filesystem
#370Earlier quoted context omitted.
In my opinion Claude should be shipped by a custom implementation of "rm" that Anthropic can add guardrails to. Same with "find" surprised they don't just embed ripgrep (what VS Code does). It's really surprising they don't just tweak what Claude uses and lock it down to where it cannot be harmful. Ensure it only ever calls tooling Claude Code provides.
All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.
Enabling Claude Code's sandbox (as OP suggested) does exactly that. It's a system-level filesystem sandbox that only permits access to specified locations for any process, including the python interpreter.