Secure sandboxing

One sudo command by agent and you are screwed

Why give it sudo access without locking it down to specific commands?

If the goal is unsupervised terminal access, I would choose a VM first, not macOS user permissions. My setup would be: UTM Linux VM with snapshots, no shared home directory one mounted project folder only, read/write if needed outbound network denied by default, then allowlist package registries only when the task needs them Docker/OrbStack is nicer for speed, but the footgun is usually the mount and network policy. A container with /Users mounted or Docker socket access is not a sandbox. For reset, keep a clean snapshot after installing the agent/runtime, run each risky task in a clone, then destroy the clone. If the agent must touch real repo files, copy the diff back out rather than letting it write directly to your main checkout.

https://github.com/rush86999/atom/blob/main/docs/architecture/SANDBOX_LAYER.md

Don't macos seatbelt or linux bubblewrap basically do the same?

I would recommend nono.sh over openshell - you don't need all the extra stuff that comes with openshell - it takes about three minutes just to boot an agent and you have to run kubernetes - nono is practically zero latency and far more powerful.

looks like another nono clone.

Why give that user sudo access? Just don't add them to the sudo/wheel group.

I use Apple's own containerization system (it's pretty new): https://github.com/apple/container I don't like a lot of the legacy baggage of docker. I've found it to work quite well. Here is my setup. Feel free to take what you need: https://github.com/0xKZ/pi-container

Hardened docker container with network egress controls.

Firecracker microVMs: https://github.com/rush86999/atom/blob/2fc001f6b8e7b1d514caff55dd4d7a5f394832e4/docs/architecture/SANDBOX_LAYER.md

Docker's Sandbox seems to be doing a good job: https://collabnix.com/running-ai-coding-agents-safely-a-hands-on-guide-to-docker-sandboxes-sbx/ Playing around with it the last few days. I tested Lume before: https://cua.ai/docs/how-to-guides/lume/install-lume which also allows sandboxing.

Use a VM and take snapshots in case if something goes wrong to restore it and call it a day

If you just want to use it for coding then consider something other than Hermes. I run MTPLX on an M5 Pro through Positron (forked VScode) and it is both easy to sandbox and can be set to require review before running certain types of commands. I’m sure that this would be possible on normal VScode. If you’re adamant on Hermes then Docker has a sandbox backend that is easy to set up.

Running a VM has so many advantages, as some have already noted here, but the ability to do a edit-undo, at an OS level is wonderful; take regular snapshots when installing new agents/skills so you can easily roll back and not leave remnants of failed experiments. My setup is here: https://alan.is/2026/07/15/openclaw-up-and-running/

Here is my take. (And yes, I'm a curmudgeonly developer who hates technology, lol.) In any case, you are completely right not to trust standard macOS file permissions. An unsupervised agent running a terminal tool with raw zsh or bash access **WILL** eventually find a way to break out or overwrite something critical if it hits a bad prompt injection. Since you are running MTPLX to pull that blazing multi-token prediction speed out of your Mac, here is how you lock down Hermes Agent without choking your performance: Do not use a heavy VM like UTM. It emulates or virtualizes an entire OS layer, which adds massive friction when trying to pass through Apple Silicon AMX/Metal acceleration smoothly from the host to the guest for your model server. Instead, split the stack: Keep MTPLX on the Host: Run the MTPLX API server (mtplx start on port 8000) directly on your bare-metal macOS. This ensures your Qwen 3.6 27B model has direct, unhindered access to unified memory and Apple Silicon GPU cores. Containerize the Agent Harness via OrbStack: Run Hermes Agent inside a lightweight Linux container. OrbStack is significantly faster and lower-overhead than standard Docker Desktop on Mac. The Lockdown Command: Spin up your container by binding only your designated workspace folder and exposing the host's network so the containerized Hermes can talk to your host's MTPLX endpoint. Bash docker run -it --name hermes-sandbox \ -v /Users/yourname/projects/agent_workspace:/workspace \ -w /workspace \ --add-host=host.docker.internal:host-gateway \ node:22-slim bash Inside that container, point Hermes to http://host.docker.internal:8000/v1 The agent can run whatever destructive terminal commands or malicious code execution loops it wants. Its entire universe is bounded by /workspace, it has zero visibility into your Mac's file system, and if it completely melts down, you can wipe it instantly: Bash docker rm -f hermes-sandbox Keep the brain on the host, put the hands in the cage. Cordially, Mike D P.S. P.S. Can't offer troubleshooting beyond this. I literally have to get back to my paying clients before I lose my job(s). Thank you. MD

https://github.com/GreyhavenHQ/greywall

Opencode in a Docker container

Look into a Docker Sandbox (relatively new, and different from and perhaps better for this purpose than a Docker Container). https://www.docker.com/products/docker-sandboxes/

if the agent can read its own code or config inside the sandbox, it can still exfiltrate through the filesystem even without network access. a lot of sandbox setups miss this. the model just needs write access to a directory that gets synced back to the host. i had an agent cleverly encode data into filenames once and the sync daemon happily carried it out. took me way too long to figure out why my supposedly secure sandbox was leaking.

I've been down this road on macOS. UTM with a minimal Linux VM is the cleanest approach I found. Alpine Linux image with read-only root, mount only the one shared folder you want the agent to see, and disable networking on the VM. Takes about 10 minutes to set up and you can trash the VM and rebuild from a snapshot in seconds if anything goes wrong. Docker/OrbStack is easier but the escape surface from a container is larger than from a full VM. The other half is what the agent does inside the sandbox. You can have perfect isolation but if your agent makes API calls or writes files that another process reads later, you still have an indirect trust boundary. I run a runtime tool-call inspector between the agent and its tools that logs every command and blocks anything not matching a policy. Happy to share the setup if you want to DM me.

Set up another user account on the mac, and run the agent as that user. Yep, mac and linux are great at multiuser stuff. File permissions/sharing etc. all bundled by default. And if it goes wrong? Delete that user and their home directory.

Use Nvidia Openshell? Personally, I have been yolo since the qwen max in qwen code cli days. All of my data is backup, projects are version controlled. If the machine breaks, I have OS on USB stick that I can reset the machine in a few minutes.

I really think you're overestimating the local AI capabilities. I guess if someone would run Fable-grade, completely jail-broken, model with a bit more interactivity than a simple prompt injection, they could make it out of standard OS sandboxing. Normal coding agent? Nah, Just run it under different user, or docker, or VM... and it will be fine. It is not that it is 100% impossible, but simple risks you're currently undertaking and accepting on daily computer use, are already much higher than "rouge super intelligent LLM". Especially if you're coding in python or JS with npm.

这条评论已被删除。