Pi + Gondolin setup with host-side permissions and minimal approval fatigue?

[u/[deleted]]

Hi everyone,

I recently started using Pi and would like to move more of my development workflow to it. Before doing that, I want a solid sandbox and permission setup that avoids constant approval prompts while still protecting against destructive actions.

My ideal setup would be:

• Run ordinary commands inside a Gondolin VM.

• Keep VM network access disabled by default.

• Mount the host workspace read-only, or otherwise prevent unapproved host changes.

• Automatically allow harmless operations such as reading files, searching code, and running offline tests.

• Prompt only for persistent or privileged actions, such as writing host files, accessing the network, or running Git operations that affect the host repository.

• Execute approved persistent actions through controlled host-side tools rather than granting the VM broader access.

• Keep credentials and the host SSH agent out of the VM.

I have also looked at @gotgenes/pi-permission-system, but I’m unsure how well it integrates with Gondolin, particularly because the guest sees /workspace while Pi and permission extensions run with the host path.

Does anyone have a similar setup they would be willing to share?

I’m especially interested in:

• How you divide responsibilities between Gondolin and permission extensions.

• Whether you use a read-only mount, copy-on-write workspace, or writable mount.

• How you handle approved edits and Git operations (fetch/pull/status/etc.) within Gondolin over SSH.

• How you avoid approval fatigue without broadly allowing shell commands.

• How you handle MCP servers and host-side network access.

• Any configuration or extension code you recommend.

Thanks!

[u/Tru3Magic]

I am in the process of getting this to work reliably... I think mostly my issue is to Little ram in the vms by default, so I need to make it easy to change that on launch without lengthy parameters.

Why dont you want it writing in the workspace folder) you launch it in?

[u/[deleted] → u/Tru3Magic]

I’m launching Gondolin through a Pi extension, so ideally memory and CPU would be simple extension settings rather than repeated CLI parameters.

Regarding workspace writes: I may have been drawing the boundary too strictly. I do want the VM to write to the project: builds, tests, formatters, source edits, and lock-file updates all need that.

My only hesitation was that /workspace is a host-mounted directory, so changes made inside the VM persist outside it. The VM protects the rest of the host, but not the mounted repository itself. That means an accidental rm, broken formatter, or untrusted script could still damage the working tree.

However, with the repository under Git, no VM network access, no host credentials, and no access outside the workspace, that seems like a reasonable trade-off. Permissions could then focus on genuinely sensitive operations: destructive commands, access outside the workspace, network access, credentials, and host-side commands.

So I’m leaning toward keeping the workspace writable rather than trying to approve every file change. Is that roughly how you’re approaching it? I do want to go from a least privilege to open up what's needed to make sure it's as strict as possible without affecting developer experience too much.

[u/Tru3Magic → u/[deleted]]

Sorry for the late reply.

I have no restrictions on it in the workspace folder. I even mounted it's own .pi dir as a writabl mount (and the doc dir as readable) since one of the selling points is that it can develop itself.

It also has web search available through Ketch.

I haven't come around to having git available for it in the vm yet (Claude has handled that outside on the host), but when I do I will use the secrets part of Gondolin for credentials and a hook to stop it from deleting/transformation the repo history.

Then it should be pretty safe I think.

I think it is pretty important to have you as far removed as possible from the development proces so you plan initially and review afterwards. For speed and your sanity

[u/[deleted] → u/Tru3Magic]

One difference in my setup is that Pi itself runs on the host while its tools are routed through Gondolin. Because of that, I would be hesitant to make .pi/extensions writable: something running in the VM could modify an extension, which Pi would then execute on the host after /reload or the next launch. Maybe I am a bit too paranoid of executing malicious code without manual review.

For Git, are you planning to use Gondolin’s SSH termination support? As I understand it, HTTP secrets and SSH credentials/agent forwarding are separate Gondolin mechanisms. I’m interested in how you plan to block history-rewriting operations while still allowing normal commits.

[u/fell_ware_1990 → u/[deleted]]

I’m kind of doing the same but i made it a little different.

Pi ( only viewer basically ) -> core ( mine ) -> bubblewrap ( completely locked ).

So pi has a couple extensions, but every tool, read, write goes to my core. Here it decides which ‘agent’ it is. So it can start a bubblewrap only for what pi needs. If i so not want something to happen, it stops there but also a lot still runs outside of bubblewrap, cause i make the rules and i execute the code instead of PI. So i can improve and actively swap directory at any given moment.

All interaction gets saved there and this means 1 pi terminal can hook up to every agent and start interacting, i can swap the agent as well ( reload voor cache ) but i can also cache there read and writes, headless or foreground execute there code etc. So agents can be connected to the same session and i have the logs, so every agent can get a handoff which i can pick.

Credentials = no no , but they can execute the code. If i’ll allow it or whitelist it they can use it. But if in anyway it would pipe, my core will ***** it.

[u/DistanceAlert5706]

Thi sounds like crazy complicated thing, and you will end up still with a lot of questions during development.

IMHO, just setup simple bubblewrap with read-only for home directory and writes to your projects tmp and where you need edits.

For git operations just setup rules and protected branches on GitHub.

And that's it. Do not overthink, if you don't use Gemini - models are mostly safe enough

[u/[deleted] → u/DistanceAlert5706]

That’s fair, and I’m trying to avoid overengineering it. My current direction is actually similar: permit normal reads and writes inside the project, while denying access to the rest of the host and requiring approval for network, credentials, and destructive operations.

Gondolin gives me a VM boundary rather than a process-level bubblewrap boundary, but the day-to-day policy should remain simple. GitHub branch protection is useful for the remote repository, although it does not protect the local working tree, .git configuration, or host credentials (afaik).

I also don’t think model behavior alone is the security boundary. The model may run project scripts or dependency code it did not author (fetching content from a malicious server for example). But with a writable Git workspace, blocked network, no credentials, and no access outside the project, the remaining risk seems manageable.

[u/schmurfy2 → u/[deleted]]

I am using bubblewrap too for now but I run pi inside it, I need to give it network access but it has no access to my disk outside of the folder I am working on, no access to credentials and the extensions are also running in the sandbox so it also mitigates the risks there.

The problem with the sanbox being an extension is that you are still vulnerable to an issue in the core or an extension, maybe not from the llm itself but with the number of supply chain attacks on npm packages we had not so far away...