CW: Have you ever been in an eating contest?
GG: Yeah, a long long time ago. I did a mashed potato eating contest at a renaissance fair back in Georgia.
I like the bubblewrap approach, it just happens to be Linux-only unfortunately. And once privileges are dropped for a process it doesn't appear to be possible to reinstate them.
> once privileges are dropped [...] it doesn't appear to be possible to reinstate them
I don't understand. If unprivileged code could easily re-elevate itself, privilege dropping would be meaningless ...
If you need to communicate with the outside, you can do so via sockets (such as the bind-mounted X11 socket in one of the readme Examples).
I happen to use a Mac, even when targeting Linux so I'd have to use a container or VM anyways. It's nice how lightweight bubblewrap would be however.
Consider one wanted to replicate the human-approval workflow that most agent harnesses offer. It's not obvious to me how that could be accomplished by dropping privileges without an escape hatch.
IIRC from a comment in another thread, it's marked as deprecated to stop people from using it directly and to use the offical macOS tools directly. But it's still used internally by macOS.
I'm pursuing a different approach: instead of isolating where Claude runs, intercept what it wants to do.
Shannot[0] captures intent before execution. Scripts run in a PyPy sandbox that intercepts all system calls - commands and file writes get logged but don't happen. You review in a TUI, approve what's safe, then it actually executes.
The trade-off vs VMs: VMs let Claude do anything in isolation, Shannot lets Claude propose changes to your real system with human approval. Different use cases - VMs for agentic coding, whereas this is for "fix my server" tasks where you want the changes applied but reviewed first.
There's MCP integration for Claude, remote execution via SSH, checkpoint/rollback for undoing mistakes.
I'm struggling to see how this resolves the problem the author has. I still think there's value in this approach, but it feels to be in the same thrust as the built in controls that already exist in claude code.
The problem with this approach (unless I'm misunderstanding - entirely possible!) is that it still blocks the agent on the first need for approval.
What I think most folks actually want (or at least what I want) is to allow the agent to explore a space, including exploring possible dead ends that require permissions/access, without stopping until the task is finished.
So if the agent is trying to "fix a server" it might suggest installing or removing a package. That suggestion blocks future progress.
Until a human comes in and says "yes - do it" or "no - try X instead" it will sit there doing nothing.
If instead it can just proceed, observe that the package doesn't resolve the issue, and continue exploring other solutions immediately, you save a whole lot of time.
You're right that blocking on every operation would defeat the purpose! Shannot is able to auto-approve safe operations for this reason (e.g. read-only, immutable)
So the agent can freely explore, check logs, list files, inspect service status. It only blocks when it wants to change something (install a package, write a config, restart a service).
Also worth noting: Shannot operates on entire scripts, not individual commands. The agent writes a complete program, the sandbox captures everything it wants to do during a dry run, then you review the whole batch at once. Claude Code's built-in controls interrupt at each command whereas Shannot interrupts once per script with a full picture of intent.
That said, you're pointing at a real limitation: if the fix genuinely requires a write to test a hypothesis, you're back to blocking. The agent can't speculatively install a package, observe it didn't help, and roll back autonomously.
For that use case, the OP's VM approach is probably better. Shannot is more suited to cases where you want changes applied to the real system but reviewed first.
Definitely food for thought though. A combined approach might be the right answer. VM/scratch space where the agent can freely test hypotheses, then human-in-the-loop to apply those conclusions to production systems.
yeah, I think the combo approach definitely has the most appeal:
- Spin up a vm with an image of the real target device.
- Let the agent act freely in the vm until the task is resolved, but capture and record all dangerous actions
- Review & replay those actions on the real machine
My issue is that for any real task, an agent without feedback mechanisms is essentially worthless. You have to have some sort of structured "this is what success looks like, here's how you check" target for it. A human in the loop can act as that feedback, which is in line with how claude code works by default (you define success by approving actions and giving feedback on status), but requiring a human in the loop also slows it down a bunch - you can end up ping-ponging between terminals trying to approve actions and review the current status.
Very cool, this sounds similar in spirit to Leash (https://github.com/strongdm/leash), especially the mac-native system extension mode of Leash (although AFAIU Leash doesn't currently have full interactive-approval mode).
ZeroFS is a single-writer architecture and therefore has overall bandwidth limited by the box it's running on.
JuiceFS scales out horizontally as each individual client writes/reads directly to/from S3, as long as the metadata engine keeps up it has essentially unlimited bandwidth across many compute nodes.
But as the benchmark shows, it is fiddly especially for workloads with many small files and is pretty wasteful in terms of S3 operations, which for the largest workloads has meaningful cost.
I think both have their place at the moment. But the space of "advanced S3-backed filesystems" is... advancing these days.
I’m building Shannot, a human-in-the-loop sandbox for AI agents on production systems.
Instead of filtering commands with heuristics (which agents work around), it dry-runs entire scripts in a PyPy sandbox, captures every command and file operation, then shows you exactly what will happen before anything executes.
I’ve just added checkpoint/rollback so you can undo changes if something goes wrong. Currently working on example scripts for common sysadmin tasks (nginx config, log cleanup, cert audits, etc.)
The gist dismisses sandbox-2 as “might as well use Docker or VMs” but IMO that misses what makes it interesting. The PyPy sandbox isn’t just isolation, it’s syscall interception with a controller in the loop.
I’ve been building on that foundation: script runs in sandbox, all commands and file writes get captured, human-in-the-loop reviews the diff before anything executes. It’s not adversarial (block/contain) but collaborative (show intent, ask permission).
Different tradeoff than WASM or containers: lighter than VMs, cross-platform, and the user sees exactly what the agent wants to do before approving.
Great documentation of the problem! The bypasses logged all stem from the same root problem: policy sandboxes give agents constraints to optimize against.
I’ve been exploring a different model: capture intent instead of blocking actions. Scripts run in a PyPy sandbox providing syscall interception so all commands and file writes get recorded. Human reviews the full diff before anything touches the real system.
No policies to bypass because there’s nothing to block! The agent does whatever it wants in the sandbox, you just see exactly what it wanted to mutate before approving.
I’ve been working on a different approach to this problem: syscall-level interception via PyPy sandbox rather than command filtering. This captures all operations at the OS level, so tmp.sh scripts and Makefile edits get queued for human review before executing.
reply