zlacker

>>speckx+(OP)
I ended up writing my own sandbox so that it works on Mac OS as well and can be used for other tools (but just AI agents) as well

https://github.com/ashishb/amazing-sandbox

>>ashish+Qf1
Curious to know what made you DIY this?

>>ATechG+6h1
Tell me a better alternative that allows me to run, say, 'markdown lint', an npm package, on the current directory without giving access to the full system on Mac OS?

>>ashish+Ih1
sandbox-exec -f curr_dir_access_profile.sb markdownlint

>>ATechG+fj1
So you have to install npm package markdownlint on your machine and let it run it's potentially dangerous postinstall step?

>>ashish+fl1
You can customize curr_dir_access_profile.sb to block access to network/fs/etc. Why is this not enough?

>>ATechG+2r1
Some tools do require Internet access.

Further, I don't even want to take the risk of running 'npm install markdownlint' anymore on my machine.

>>ashish+Gt1
I understand the concern. However, you can customize the profile (e.g., allowlist) to only allow network access to required domains. Also, looks like your sandboxing solution is Docker based, which uses VMs on a Mac machine, but will not use VMs on a Linux machine (weak security).

>>ATechG+HU1
That's why I wrote my own sandbox. Everyone hand waives these concerns.

Further, I don't know why docker is weak security on Linux. Are you telling me that one can exploit docker?

>>ashish+fZ1
dockerd is a massive root-privileged daemon just sitting there, waiting for its moment. For local dev it’s often just unnecessary attack surface - one subtle kernel bug or namespace flaw, and it’s "hello, container escape". bwrap is much more honest in that regard: it’s just a syscall with no background processes and zero required privileges. If an agent tries to break out, it has to hit the kernel head-on instead of hunting for holes in a bloated docker API