GSoC 2026 — Idea #8: Native Windows Sandbox using AppContainer

[AnushkaPandit-21]

Hi everyone! 👋

I'm Anushka Pandit, a 4th-year CS student at BITS Pilani, and I'm applying for Idea #8: Native Windows Sandbox using AppContainer for GSoC 2026.

What I've Done So Far

Working Proof of Concept

I've built a fully functional Node-API (C++) addon demonstrating:

• AppContainer process isolation — CreateAppContainerProfile, capability SIDs, ACL-based filesystem gating
• WFP network filtering — block-all default + per-endpoint allow rules using FwpmEngineOpen0 / FwpmFilterAdd0
• Full Seatbelt parity mapping — all 6 macOS profiles (permissive/restrictive/strict × open/proxied) mapped to AppContainer equivalents

🔗 PoC repo: https://github.com/AnushkaPandit-21/appcontainer-node-sandbox

Contributions to gemini-cli

• PR test(core): add missing tests for errorClassification #20759 — test(core): add missing tests for errorClassification
• PR fix(core): use path.sep in grep test assertions for Windows compatibility #20871 — fix(core): use path.join in grep test assertions for Windows compatibility
• Issue feat(sandbox): add Windows platform detection in sandboxConfig.ts #20780 — feat(sandbox): add Windows platform detection in sandboxConfig.ts

Integration Plan

I've identified 3 hook points in the existing codebase:

1. sandboxConfig.ts:getSandboxCommand() — add win32 platform detection
2. sandbox.ts:start_sandbox() — dispatch to AppContainer launcher
3. New packages/windows-sandbox/ — native addon package

Questions for Mentors

1. Should the AppContainer addon live in a separate packages/windows-sandbox/ or within the existing CLI package?
2. What's the preferred approach for the prebuilt binary distribution — prebuildify or node-pre-gyp?
3. Are there specific test infrastructure requirements for Windows CI?

@gsquared94 — Would love your feedback on this approach!

Looking forward to connecting with mentors and other contributors. 🙏

[AnushkaPandit-21]

PoC Update - Build & Tests Passing on Windows 11
Just pushed fixes for CommonJS compatibility and WFP type alignment (commit). Both tests pass end-to-end:

Test A: Sandboxed process attempts write to C:\Windows\ → Access Denied (AppContainer blocks it)
Test B: Sandboxed process writes to ACL-granted working directory → Success
This confirms the full pipeline works: CreateAppContainerProfile → ACL setup via SetNamedSecurityInfo → CreateProcessW with SECURITY_CAPABILITIES → FwpmFilterAdd0 for network isolation → cleanup via DeleteAppContainerProfile.

Screen.Recording.2026-03-06.061906.mp4

Up next:

IPv6 WFP layer support (FWPM_LAYER_ALE_AUTH_CONNECT_V6)
LPAC (Less Privileged AppContainer) for strict-* profiles
Benchmark: AppContainer startup latency vs Docker on Windows
cc @gsquared94

[manas-raj999]

Hi Anushka, this is honestly a really impressive exploration of the Windows sandboxing space. I’m currently studying the Gemini CLI codebase as well, and seeing a working PoC around AppContainer isolation and WFP-based network filtering was actually inspiring like why didn't i do that.

I especially liked how you mapped the existing macOS Seatbelt profiles to AppContainer equivalents ,that kind of parity thinking seems important for keeping sandbox behavior similar across different platforms.

One thought that came to mind while reading your integration plan: since Gemini CLI already relies on different sandbox mechanisms across macOS and Linux, do you think it might eventually make sense to introduce a more personal kinda cross-platform sandbox abstraction layer in the CLI?

For example, if each OS backend (Seatbelt, bubblewrap, AppContainer) exposes slightly different capabilities around filesystem or network policies, the CLI might eventually need a common interface that normalizes those behaviors. I’m curious whether you’ve thought about how AppContainer capabilities might map into such a model if the sandbox system evolves further in the future.

Also really cool to see a PoC already validating things like ACL-restricted filesystem access and blocked writes to protected directories -that’s a great proof that the approach is viable, its like you are already selected.

Looking forward to seeing where this goes. It definitely motivated me to dig deeper into the sandbox architecture in the repo.

[AnushkaPandit-21]

Thanks Manas!

So the cross-platform abstraction idea,I actually thought about this while working on the PoC.
The three backends work very differently under the hood:

Concern	Seatbelt (macOS)	Bubblewrap (Linux)	AppContainer (Windows)
FS isolation	Path-based deny rules	Mount namespace (bind-mount allowlist)	SID-based ACLs on securable objects
Network	Seatbelt network* filters	Seccomp + netns	WFP filter engine (per-layer BFE rules)
Process	Sandbox profile inheritance	PID namespace + seccomp-bpf	AppContainer token (inherited by child)

So you can't really abstract the mechanism itself — they're too different. What you can do is have a common policy layer that describes intent, like { fs: "read-only", network: "api-only", allowPaths: [...] }, and let each backend figure out how to enforce it natively. The existing SandboxConfig in sandboxConfig.ts already does some of this with the profile concept (default / strict-*).
The capabilities aren't symmetric. So you'd need a baseline that works everywhere + optional extensions for platforms that support more.

The WindowsSandboxProvider I'm building would implement the same SandboxProvider interface the existing backends use, so it should fit into this kind of model pretty naturally.

[aniruddhaadak80]

From my point of view, the proposal looks serious because it is grounded in an actual AppContainer proof of concept instead of only a high level plan. The next thing that would make it even stronger is a clear compatibility story for how capability differences are normalized so users do not get materially different sandbox expectations across platforms. A thin common policy model with backend specific lowering feels like the right direction.