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?

▲

ghm2180 2 hours ago | parent | next [-]

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.

	▲	neobrain an hour ago \| parent [-]
		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.

▲

0kk33 3 hours ago | parent | prev | next [-]

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

	▲	neobrain an hour ago \| parent [-]
		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 :)

▲

ghm2180 2 hours ago | parent | prev | next [-]

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.

▲

agentdev001 2 hours ago | parent | prev [-]

Take a look at Nvidia OpenShell, and their dev blogs on it. That seems like what you're looking for.

	▲	neobrain an hour ago \| parent [-]
		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!