6 ms·
What is an easy way to achieve this on a Mac? tl;dr: if I run claude/harness inside "code" at "~/<some path>/work/code", it would be great if the harness can't
by shelled 1mo ago
What is an easy way to achieve this on a Mac?
tl;dr: if I run claude/harness inside "code" at "~/<some path>/work/code", it would be great if the harness can't even see "code" is inside "work" (and even I can't make it know that by some quick "Yes(y)")
I want something like: claude/opencode/pi/etc has no existence or capacity outside a file access boundary, say a given folder that (e.g.) lies here "~/<some path>/code". Even if I want, I can't run claude outside it, because it isn't installed outside it. Even if Claude wants it can't read/write/execute/install anything outside it.
Basically I want the harness(es) and my code folder(s) sandboxed [0] inside just one folder and below it in folder hierarchy at least for file access limitations.
Will this pose the challenge of using the system wide cli tools like ls, cd, git et cetera? If it gets a handle on those tools outside that sandboxed folder then pretty much can it execute it in any other folder? So should those tools also be part of that container?
I guess something like docker does that, but do I necessarily need a docker like app/tool? It will use a lot of system resources on its own. A different mac login won't be great either.
I do not want to use claude's /sandbox (or something like this), that will defeat the purpose. Because it's not about "it won't", but because "it can't".
https://github.com/apple/containerization https://github.com/apple/containerization doesn't sound like what I am looking for. So is docker, lima etc are my only options? Not to mention I will lose access to a lot of cli tools I use on mac.
- frumiousirc 1mo agoI use bubblewrap, which I believe claude code also has internally but not for its `Bash()` tool. I wrap bubblewrap in a script that supports config files to allow different "profiles" of use (analogous to eg firefox profiles). The bwrap starts with the whole filesystem mounted read-only, then mounts the current directory read-write and then applies further bind mounts for devices, special case other read-write (eg, ~/.cache/) and to mount empties to cover sensitive directories (eg, ~/.ssh/). The profile also specifies the default command to run and for claude, it gets yolo mode.
- e1g 1mo agoOn a Mac, you can do this via OS-native Seatbelt sandboxing - you define a static text file and it locks down the process so it can't read/write anything it's not supposed to. The syntax is a bit archaic, so I built a Bash wrapper around it to dynamically detect which agent you use and from what dir, and then generate the policy to lock down its process - https://github.com/eugene1g/agent-safehouse https://github.com/eugene1g/agent-safehouse
- shelled 1mo agoHey, thank you. Looks like a tool easy enough to use and start with the agentic world in a sandboxed and much safer manner. Just clarifying a bit (haven't gone through details yet): 1. So, a harness gets installed within the bounds of this script via agent-safehouse? (I doubt this is the case) 2. Or they are installed as a normal app, but when I run them in the terminal within the bounds of "safehouse <harness>" (saw this) they are bound by the rules I set, right? I feel it's the latter and I think it's good enough for the time being. ..... Mac offers some controls at least for personal files and "Full Disk Access" etc. But it's so badly implemented and poorly shown that it's confusing. Like I can see in "Privacy & Security > Full Disk Access" OpenCode is listed and and "Full Disk Access" toggled off. (I anyway remove OpenCode from here completely by the "-" button after selecting it, just to make sure). Then I go back a step and in "Privacy & Security > Files & Folders > OpenCode" has "Full Disk Access" is listed there. Strange!
- e1g 1mo ago“safehouse <harness>” hides and protects your filesystem from the agent CLI - it cannot read/write/delete anything outside of the current folder, no matter what Bash/code it tries (short of finding some 0-day within MacOS sandboxing). We added exceptions for dev tooling (so eg NPM works), but generally keep same defaults (eg no Docker access by default as having that socket bypasses all protection)