I’m currently running opencode and claude as my own user. typically with tmux / bash.
If I don’t give the AI general permission to run everything it’s really increasing friction and capabilities A LOT. So I really would prefer it to run unsupervised. However, I still will typically watch it because I’m just not entirely free of paranoia something terrible will happen.
So I was wondering if there are some guardrails I can put up that won’t be relying on the harness. I was thinking something along the lines of creating a seperate AI user with read permissions on the stuff it wants to read but without write permissions for my home directory. I think this wouldn’t be to hard to do with ACLs, but I was wondering if this is the best way to go about it.
others have probably had similar thought and came up with solutions already, what are your takes?
All of the above? I mostly thought about write / deletion, as these would be the most pita. I don’t think I care to much about document sniffing or secret bot net agents. Or deem the risk acceptable.
You can create a Dockerfile with all your standard tooling in it (compilers, interpreters, build systems, etc.) as well as your harnesses like Opencode. Then -v your workspace and ~/.config/opencode. Create a user in the Dockerfile and have it run as that user instead of root. You can give it your UID so it can read/write to the workspace in the volume mount.
You can set the entrypoint to your harness (e.g. opencode). Alternatively you can set the entrypoint to something like cat or sleep, then just exec into the running container to start the harness or whatever other tools you want.
I’ve been meaning to do this myself. I do tend to run Opencode and Claude Code just as my regular user and it’s starting to worry me too.
I use a WSL ubuntu in windows and on my linux machine a devcontainer (setup with vscode). Anything it screws can just be rolled back!
With the docker container you can also give read-only access to your folders.
WSL can access all files on your user can within Windows machine so it won’t stop anything malicious like a credential stealer in some nodeJS or pip package.
Dedicated VMs are the way. Container escape is too easy. Bonus points for VMs with no internet access. Just one path to the local model and any MCPs the agents should be using.
Honestly I build a dedicated machine for agents I want to allow to run wild and don’t login or enter any passwords / wallet that would allow it to have access to anything specific to ‘me’. Mostly for experimentation however. - Suggesting if you have a pc, laptop, mini junk laying around.
I have a VM strictly for dev projects that has tmux sessions of Claude CLI running at each project root. I also started working on a global ruleset to templatize new projects while also keeping track of project-level nuances (it also allows me to just update gsd-core in one place rather than in every project).
Project repos live in a locally-hosted Gitea instance so any code issues can be rolled back.
Anything that Claude touches outside of the VM goes through a narrowly-defined connector (API, MCP, etc).
I’d run the harness under bubblewrap (bwrap), which gives it read-only access to the whole filesystem and write access only to the project and the harness’s own state. Run bwrap --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp --tmpfs ~/.ssh --bind ~/project ~/project --bind ~/.config/opencode ~/.config/opencode --bind ~/.local/share/opencode ~/.local/share/opencode --chdir ~/project opencode from your normal shell. For Claude Code, bind ~/.claude and ~/.claude.json the same way. Anything outside those binds is read-only inside that session, and the tmpfs over ~/.ssh hides your keys. It shares the network and the kernel with your session, so it covers accidental writes and deletes but not a malicious package.
Wow, quite a few answers. It seems like more isolation is favored. I already knew docker or a VM could be a solution, but just wasn’t sure if that wasn’t overkill for my somewhat mediocre security concerns. But is there a reason extra user + ACL would be a bad idea?
Hm… I always find web search to be one of the more useful features. And I also enjoy some frontier models. Not really interested in local only, mostly because I lack the money to host a model with which I’d be satisfied I fear. But who knows, I’ve seen some of your posts and perhaps there are some cheap gains to be had, still reading up on those
An extra user with ACLs would work, but I’d move the project outside your home to something like /srv/projects so the agent user needs no access to your home directory. Then run sudo setfacl -R -m u:aiuser:rwx,d:u:aiuser:rwx,d:u:yourname:rwx /srv/projects so files either of you creates stay editable by both. Sign the harness in as that user with sudo -iu aiuser so its config and tokens live in its own home.
