Yes, it needs to be sandboxed very carefully. It should have no way to access anything outside of the directories you mount in the sandbox.
replyI wonder what is the approach you taking? In my dev env we have .env files that supposed to have dev api keys for staging and testing. Production parameters stored in parameter store. There is also deploy script, that can deploy into production given there is a token in AWS CLI.
replyI understand there is a way to keep Claude inside working dir. but how to limit it from accidentally deploying production, modifying terraform deleting important resources? If dev can run AWS cli ir terraform then Claude can…
I do not use claude and will use agents only when I am forced to, so I'm genuinely asking here:
replyCan claude or other models not be run as a user or program with limited permissions? Do people just not bother to set it up? Why on earth would anyone run an RNG that can access $HOME/.ssh?
There's absolutely nothing special about any of these agents. They're regular processes that execute some subshells. They're trivially jailable.
replyThey absolutely can. I used to run Claude Code inside a firejail. Then I got paranoid to the point I developed my own virtual machine orchestration system just so I could run fully virtualized and isolated per-project Claude Code instances.
replyDo you have more information on this?
replyMore information on what exactly? The firejail, or my VM orchestration project?
replyThe latter is here:
https://github.com/matheusmoreira/virtdev
I've been using it every day. Just implemented easy backup and restore.
There are many useful tools for easily sandboxing agents. Visual Studio Code has devcontainers, which are trivially used.
reply