Comment by neobrain
12 hours ago
Do any of these sandboxing solutions have a dynamic component to them that lets you grant permissions, starting with a minimal sandbox and asynchronously adding permissions as they become necessary? Harnesses try to do this when accessing non-project folders, but it's not always strictly enforced and generally not revocable. Harnesses also block agent execution until a decision is made, which requires constant monitoring to ensure progress can happen when the agent could easily proceed with an alternative method right away.
I like the idea of a minimal sandbox that protects against accidental `rm -rf` and against personal data leakage, but such a setup then often gets in the way of the specific task to be done. Ideally the sandbox would be able to aggregate blocked accesses and then expose them in an external TUI dashboard, where I can then enable access (without blocking any running agent on this, since that's prone to "press okay" fatigue).
Does anything close to this exist yet?
If I understand you correctly https://nono.sh/ might go into that direction. It can add permission after the sandboxed command is terminated based on which blocks occurred. Its not life though as you seem to describe
Very interesting concept to make permissions specific to individual shell commands though. Certainly good that people are experimenting with these approaches, hopefully ideas will eventually converge so we don't need to know like a 100 different sandbox projects :)
I couldn't get cline TUI to run in it though. Apparently node does fancy temp folder things and it just wouldn't go
If only we had a decent capability based OS. Then all processes would have the property you're after. If you want it to be able to write to a disk, dependency inject a disk writing capability. Need to talk to a remote host, provide a handle for just that host.
Don't want these capabilities? Do nothing, that's the default state.
Unfortunately, capabilities based OSes, or written in mostly safe systems programming languages aren't by lack of trying.
However outside mainframes and micro-computers, or niche deployments, adoption has been a challenge.
iOS/macos and linux both support capabilities, now the depth of those capabilities in all cases might lack depth but people are moving in this way.
2 replies →
Not associated with the project but have been following the development, https://5bsd.org/ could be a good answer. Kory’s been adding capability enforcement for the Linux APIs on top of BSD kernel (among other cool features).
Fuchsia is an “option”, although it doesn’t support much hardware without writing your own drivers.
I think this may be a false choice because of the work pattern you might be used to. Assuming here, If you work in interactive sessions where it's open ended there is a boundary where you have done enough research/prototyping and you need to move to implementation and the permission scope has to change now. I think the realization that you might have is that if you're doing this then it's probably best to separate the automated AFK part from your initial research part.
Even for pure research/prototyping, you quickly run into the problem that your sandbox is either prohibitively minimal or overly permissive. Depending on the exact task, you may need GPU access, Docker/Nix socket access, ability to ptrace processes (gdb), run webfetches, etc. If I define a "research" sandbox profile to allow all of these, I might as well not have any sandbox at all.
I have faced this exact dilemma as well. It's not always clear what permissions are needed in advance for my pi sessions and it's child sub sessions. A simple example is when child sessions do a task they locally want to fire random docker commands to learn the state of my local docker devstack.
Take a look at Nvidia OpenShell, and their dev blogs on it. That seems like what you're looking for.
Sounds OpenShell locks filesystem access on sandbox creation - arguably the most important isolation feature, at least for my use cases. Architecturally it looks right though!