4 ms·

Is there any way to do this with user permissions instead? I feel like it should be possible without having to run a full container? Any reason we cannot setu

Is there any way to do this with user permissions instead? I feel like it should be possible without having to run a full container? Any reason we cannot setup a user and run the program using that user and it can be contained to only certain commands and directory read write access?

Finbarr 9mo ago
Could do but part of what I find super useful with these coding agents is letting them have full sudo access so they can do whatever they want, e.g., install new apps or dependencies or change system configuration to achieve their goals. That gets messy fast on your host machine.
- beepbooptheory 9mo ago
  But then what do you do with that? Is the software distributable/buildable outside of the container after all that?
  - Finbarr 9mo ago
    When you run yolobox, the current directory is shared fully with read-write with the container. That means anything the AI changes will be on your host machine also. For max paranoia, only mount git repos that are clean and pushed to a remote, and don’t allow yolobox to push.
    - jaggederest 9mo ago
      You could go a step further in paranoia and provide essentially just a clean base image and require the agent to do everything else using public internet - pull your open source repo using an anonymous clone, make changes, push it back up as an unprivileged account PR. For a private repo you would need slightly more permissions, probably a read-only SSH key, but a similar process.
vunderba 9mo ago
Yeah that's similar to my approach. I created a non-admin account on my Mac to use with OpenCode called "agentic-man" (which sounds like the world's least threatening megaman villain) and that seems to give me a fair amount of protection at least in terms of write privileges. Anyone else doing this? EDIT: I think it'd be valuable to add a callout in the Github README.md detailing the advantages of the Yolobox approach over a simple limited user account.
saltypal 9mo ago
Check out https://github.com/anthropic-experimental/sandbox-runtime https://github.com/anthropic-experimental/sandbox-runtime, which tackles this problem using the built-in userspace sandboxing on macOS and Linux. I run Claude from a mounted volume (but no reason you couldn't make a user for it instead) since the Deny(~) makes it impossible to run from the normal locations. export CLAUDE_CONFIG_DIR=/Volumes/Claude/.claude Minimal .claude/settings.local.json: { "permissions": { "allow": [ "Read(/)", "Read(~/.claude/shell-snapshots/\*)", "WebSearch", "WebFetch(domain:example.com)" ], "deny": [ "Read(~)", "Write(/.claude/settings.local.json)", "Write(/method_filter.py)" ] }, "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true, "allowUnsandboxedCommands": false, "network": { "allowLocalBinding": true, "httpProxyPort": 9655 } } }

Finbarr 9mo ago

Could do but part of what I find super useful with these coding agents is letting them have full sudo access so they can do whatever they want, e.g., install new apps or dependencies or change system configuration to achieve their goals. That gets messy fast on your host machine.

beepbooptheory 9mo ago
But then what do you do with that? Is the software distributable/buildable outside of the container after all that?
- Finbarr 9mo ago
  When you run yolobox, the current directory is shared fully with read-write with the container. That means anything the AI changes will be on your host machine also. For max paranoia, only mount git repos that are clean and pushed to a remote, and don’t allow yolobox to push.
  - jaggederest 9mo ago
    You could go a step further in paranoia and provide essentially just a clean base image and require the agent to do everything else using public internet - pull your open source repo using an anonymous clone, make changes, push it back up as an unprivileged account PR. For a private repo you would need slightly more permissions, probably a read-only SSH key, but a similar process.

vunderba 9mo ago

Yeah that's similar to my approach. I created a non-admin account on my Mac to use with OpenCode called "agentic-man" (which sounds like the world's least threatening megaman villain) and that seems to give me a fair amount of protection at least in terms of write privileges. Anyone else doing this? EDIT: I think it'd be valuable to add a callout in the Github README.md detailing the advantages of the Yolobox approach over a simple limited user account.

saltypal 9mo ago

Check out https://github.com/anthropic-experimental/sandbox-runtime https://github.com/anthropic-experimental/sandbox-runtime, which tackles this problem using the built-in userspace sandboxing on macOS and Linux. I run Claude from a mounted volume (but no reason you couldn't make a user for it instead) since the Deny(~) makes it impossible to run from the normal locations. export CLAUDE_CONFIG_DIR=/Volumes/Claude/.claude Minimal .claude/settings.local.json: { "permissions": { "allow": [ "Read(/)", "Read(~/.claude/shell-snapshots/\*)", "WebSearch", "WebFetch(domain:example.com)" ], "deny": [ "Read(~)", "Write(/.claude/settings.local.json)", "Write(/method_filter.py)" ] }, "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true, "allowUnsandboxedCommands": false, "network": { "allowLocalBinding": true, "httpProxyPort": 9655 } } }