[CRITICAL][BUG] Gemini in Sandbox Fails to Run or Acess env Variables, orphaned AppContainer IDs that break Discord, Antigravity 2.0, and other Electron apps

Google Antigravity
,
1

Summary

Antigravity IDE is repeatedly creating orphaned AppContainer SIDs / user-account SIDs on my system. Every time this happens it (a) breaks the IDE’s own sandboxed terminal so the integrated AI agent can’t execute even trivial commands, and (b) eventually causes unrelated Electron-based apps (Discord, and even Antigravity itself in some sessions) to stop launching or freeze, until I manually clean the orphaned SIDs from the ACLs. This is a recurring, disruptive issue and I’d like it treated as high priority.

Environment

  • OS: Windows 11 Home, 25H2
  • Antigravity IDE version/build: 2.0.4
  • Installed via: Antigravity Website

Description

After using Antigravity for a while (no consistent trigger I’ve isolated yet — happens across normal coding sessions), new orphaned AppContainer SIDs and user SIDs accumulate on the file ACLs.
These are leftover security identifiers with ERROR_NONE_MAPPED when resolved — i.e., the IDE is creating containers/profiles and not cleaning them up correctly on teardown.

Symptoms

  1. Sandbox terminal breaks entirely. The integrated AI agent frequently cannot run any command in its sandboxed terminal — not even a single echo statement. It reports that “the environment is not available” and that no other sandbox facilities are accessible. This makes the agent’s terminal feature completely unusable until the SIDs are cleared.

  2. Orphaned SIDs pile up with repeated use. Each session seems to leave behind new orphaned AppContainer/user SIDs rather than cleaning up after itself. Over time these accumulate across the filesystem ACLs.

  3. Electron apps stop working as a side effect. Once enough orphaned SIDs accumulate, other Electron-based applications start failing too — Discord stops launching/working correctly, and even Antigravity 2.0 itself can become unresponsive. The only fix I’ve found is to manually go in and strip the orphaned SIDs from the affected ACLs, after which things work again — until the cycle repeats.

Impact

This is genuinely disruptive — it derails active coding/agent sessions with no warning, and I’ve had to repeatedly stop work to manually fix file permissions just to get Discord or Antigravity itself back to a working state. Having to do this repeatedly, with no clear trigger and no in-app way to resolve it, has been a significant source of stress, and I’d like a real fix rather than a workaround.

Steps to Reproduce

  1. Use Antigravity normally for an extended session (agent + terminal use).
  2. At some point, the agent’s terminal commands begin failing with an “environment not available” type error.
  3. Check file/folder ACLs (icacls or Get-Acl) — orphaned AppContainer/user SIDs are present and unresolvable (ERROR_NONE_MAPPED).
  4. Other Electron apps (Discord, Antigravity itself) begin failing to launch or hang.
  5. Manually removing the orphaned SIDs from ACLs temporarily resolves both issues.

Current Workaround

I’ve had to write my own PowerShell cleanup script to detect and strip orphaned AppContainer/user SIDs from file ACLs (with dry-run support) since there’s no built-in way to do this from within Antigravity. This shouldn’t be necessary — the IDE should be cleaning up its own sandbox containers on exit/crash.

Request

Please look into why AppContainer/SID cleanup isn’t happening on sandbox teardown, and fix this so:

  • Orphaned SIDs aren’t left behind after normal use or crashes.
  • The agent terminal degrades gracefully (or self-heals) instead of going fully dead.
  • This doesn’t cascade into breaking unrelated Electron apps on the system.

Happy to provide logs, Process Monitor traces, or the exact orphaned-SID list if that helps triage this faster.