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?

▲ saltypal 11 hours ago | parent | next [-]

Check out 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
        }
      }
    }

▲ vunderba 16 hours ago | parent | prev | next [-]

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.

▲ Finbarr 17 hours ago | parent | prev [-]

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 17 hours ago | parent [-]

But then what do you do with that? Is the software distributable/buildable outside of the container after all that?

▲

Finbarr 17 hours ago | parent [-]

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 10 hours ago \| parent [-]
		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.