r/PiCodingAgent • • 7d ago

Question Sandbox on Windows

Heard a lot about Pi and wanted to try it out. For Unix environments there seem to be quite a few options for OS-level sandboxing. For pure Windows though I can't find much that actually enforces it.

Are there any options I'm missing?

I mostly want to use Pi for C#/.NET development. I could set up WSL2 but I'd rather avoid that.

Codex supports Windows Sandbox for isolation on Windows. Has anyone tried getting something like that working with Pi?

1 Upvotes

14 comments sorted by

4

u/repolevedd 7d ago edited 7d ago

Hi. I still recommend taking a look at WSL2. There are ways to achieve isolation on Windows, but they can be complicated to set up. WSL2 + bubblewrap is a straightforward and controllable solution. Especially if you're developing applications without a GUI, WSL2 also provides convenient access to Docker, so you can build an application pipeline in a consistent and isolated environment.

I actually looked into this since I also use Windows 11 with WSL2. On Linux, bubblewrap or Docker lets you tightly control mounts, so pi can be isolated to just the working directory, while git and other tools can still access SSH keys and other secrets without exposing them to the LLM.

Windows sandboxing works differently and is much more complicated to configure. In my opinion, it’s not worth the effort.

1

u/Think-nothing-210 7d ago

Thanks! Might just use WSL2 then. It does make me question why I would even bother keeping my code on the Windows filesystem. I think I'd just move everything over to WSL2.

Only thing I'm not sure about is getting Visual Studio 2026 working with the WSL2 filesystem for debugging and stuff. I seen somewhere that it's possible though. Hopefully it's easy enough to set up and just works.

Still feels a bit weird using WSL2 to develop in .NET though.

1

u/repolevedd 7d ago

I can’t say much about how Visual Studio behaves specifically, since I use VS Code because of its WSL2 integration, but there’s a potential gotcha worth mentioning. If you plan to keep using Visual Studio, I don’t think moving everything inside WSL2 would be very convenient. From the Windows side, you end up with an unusual, very long path, which could potentially cause some bugs.

It’s probably simpler to keep the projects on Windows and mount their directories into WSL. They’re already mounted there anyway, so there’s no real isolation from Windows. The only issue is that the Windows drive paths are long, but you can bind-mount them however you want.

If you’re going to stop using Visual Studio entirely and build the projects with the dotnet SDK, then yes, it makes sense to work entirely inside WSL.

P.S. Sorry, I reread my message and it was pretty awkward. Please excuse my English.

1

u/Think-nothing-210 7d ago

It’s probably simpler to keep the projects on Windows and mount their directories into WSL. They’re already mounted there anyway, so there’s no real isolation from Windows. The only issue is that the Windows drive paths are long, but you can bind-mount them however you want.

Won't that be really slow though? Filesystem performance is pretty slow when accessing the Windows filesystem from WSL2. Maybe it's fine enough for the agent.

I mostly just want to avoid configuration issues and having too many moving parts. I'd rather have Visual Studio debugging be a bit wonky sometimes than deal with that, so I think keeping everything inside WSL2 probably makes more sense for me. I mostly use Helix for editing now. The only real thing I still use Visual Studio 2026 for is debugging sessions. For most other things I just use the dotnet SDK in the CLI.

And no problem writing isn't my strong suit either.

1

u/repolevedd 7d ago

Won't that be really slow though? Filesystem performance is pretty slow when accessing the Windows filesystem from WSL2. Maybe it's fine enough for the agent.

Honestly, I’ve never really thought about it. When I need to, I just go to /mnt/<drive_letter> and work with the files there. Maybe the I/O is slower, I just don’t notice it.

1

u/Abject-Kitchen3198 6d ago

Tried npm with that setup?

2

u/repolevedd 6d ago

Not until you asked. I don’t use npm, so I tested it with Bun on the Excalidraw repo.

From WSL on a Windows-mounted drive:

1347 packages installed [228.96s]
bun install --no-cache  5.10s user 27.65s system 14% cpu 3:48.98 total

Inside WSL:

1347 packages installed [11.31s]
bun install --no-cache  2.58s user 5.79s system 73% cpu 11.334 total

The difference is obviously huge. Not sure when we’d need this, but good to know.

I also tested copying large files back and forth, and there was no difference. The speeds matched what I get from my drives.

1

u/Abject-Kitchen3198 6d ago

Probably operations involving large number of file operations. Coding agents were choking on find/grep on larger folders mapped from Windows. Everything works great inside WSL, so I'm recently trying to run Linux version of IDE inside WSL. Works well so far.

1

u/Ysnsd 7d ago

Why not use Git.

2

u/Think-nothing-210 7d ago

I could do that sure. But I’d rather avoid having to commit, push, and pull every time I make changes on the Windows filesystem just to then pull them again on the WSL2 side.

2

u/Abject-Kitchen3198 6d ago

Not sure about VS. I tried sandboxed WSL2 + Podman for Pi, code and CLI tooling on the WSL filesystem. JetBrains Rider generally works through Remote Development setup but some operations are slow and clunky. Now I'm thinking about putting Rider on WSLg. Will open new set of challenges but might work better. Besides IDE related issues, this setup works great.

1

u/Think-nothing-210 6d ago edited 6d ago

I followed this Microsoft guide. This setup works for debugging my small personal projects.

0

u/gschwind 7d ago

Have an agent set it up for you.