forge-v2: perf(sandbox): optimize Windows sandbox initialization via native ACL application

[kimjune01]

Forge-v2 refactored version of google-gemini/gemini-cli#25077

Original PR

perf(sandbox): optimize Windows sandbox initialization via native ACL application

Summary

This PR optimizes the Windows sandbox initialization performance by offloading file system ACL modifications from Node.js to the native C# helper (GeminiSandbox.exe). This eliminates the overhead of spawning multiple icacls.exe processes.

Details

• Native ACL Application: Updated GeminiSandbox.cs to apply ACLs natively using .NET's FileSystemSecurity and P/Invoke (SetNamedSecurityInfo).
• Bulk Processing via Manifests: WindowsSandboxManager.ts now aggregates allowed and forbidden paths into temporary manifest files, which are passed to the helper via --allowed-manifest and --forbidden-manifest flags.
• Improved Isolation: The native helper now sets the "Low Mandatory Level" integrity label and adds explicit "Deny FullControl" rules for forbidden/secret files directly in the process setup phase.

Related Issues

N/A

How to Validate

Execute the unit and integration tests on a Windows environment:

npm run test -w @google/gemini-cli-core -- src/sandbox/windows
npm run test -w @google/gemini-cli-core -- src/services/sandboxManager.integration.test.ts

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
  • Windows
    • npm run
    • npx
    • Docker
  • Linux

---

Forge-v2 pipeline results

Metric	Value
Blind-blind winner	codex (Opus 4.6 vs Codex GPT-5.4)
Build + tests	PASS
Complexity gate	Δ=0 (PASS)
Gemini reviewer	✅ Approved ("No comments")

Refactoring claims applied

• C1 — Name the low-integrity SID once
• C2 — Extract low-integrity label application
• C3 — Split per-path ACL mutations from the bulk loop
• C4 — Factor manifest file creation

What is this?

This diff shows the output of a forge-wrapped LLM refactoring pipeline applied to PR google-gemini#25077's code at the point where tests first passed (C_test). The question: can an autonomous pipeline improve the implementation before human review?

Pipeline: goal-anchored volley → adversarial hunt-spec → blind-blind implementation (Opus 4.6 + Codex GPT-5.4, smaller-churn wins) → hunt-code with full build+tests → Gemini 3.1 Pro reviewer-loop → complexity gate (δ=0.05).

Experiment: refactor-equivalence v2 — Does an LLM refactoring pass help or hurt brownfield PRs?

We'd love your take: would you approve this diff? 🙏