[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.

2

Hi, can you provide the workaround steps to resolve this issue, I am facing the same issue with my antigravity ide whenever executing a cli command it gives error: opening NUL for ACL write: Access is denied

3

(post deleted by author)

4

I was experiencing the exact same opening NUL for ACL write: Access is denied error with Antigravity on Windows 11.

What eventually worked for me was manually cleaning up the orphaned SIDs and resetting/removing the affected Antigravity data.

What I did:

  1. Completely closed Antigravity.
  2. Used Administrator PowerShell to take ownership and reset the ACLs on:
    C:\Users\EMMA\.gemini\antigravity-ide
  3. Deleted the antigravity-ide folder completely.
  4. I also checked the .gemini directory and removed the remaining Antigravity-related folders before reinstalling.
  5. Uninstalled and reinstalled Antigravity.
  6. After reinstalling, the terminal was still initially affected, so I checked the orphaned SIDs elsewhere under .gemini\config.
  7. I confirmed that Windows itself could write to NUL normally with:
    cmd /c "echo normal-user-test > NUL"
    and $LASTEXITCODE returned 0.

After the cleanup/reinstall, Antigravity’s terminal eventually started working again. The important part seems to be that the problem wasn’t actually a broken Windows NUL device. Windows could access NUL normally. The issue appears to be related to the permissions/security context used by Antigravity’s sandbox.

Hopefully this helps. The NUL ACL error is particularly misleading because icacls C:\Windows\System32\NUL itself returns “The parameter is incorrect,” while normal redirection to NUL works perfectly.