OS : Windows 10 IoT Enterprise Edition LTSC
VERSION : 21H2
since antigravity ver 1.21.6, Windows OS can no longer execute any commands in cmd and PowerShell terminal. How can I solve this problem?
Same problem. Win11 Pro 25H2.
I’d even be happy to have instructions to tell it not to do whatever it is trying to do. But so far nothing I tried works. E.g.
Never set SafeToAutoRun: true on run_command calls. Windows does not
support the auto-run sandbox. Always require explicit user approval
(SafeToAutoRun: false).Same here
Windows 11 Home 25H2
Tried enabling virtualization and reinstalling, but neither of those worked
Same issue here, chaning any settings doesn’t help.
Hey, thanks for your comment. However, my topic is about Windows OS, and this document is for Linux and macOS.
Thank you for bringing this to our attention. We have escalated the issue to our internal teams for a thorough investigation.
To ensure our engineering team can investigate and resolve these issues effectively, we highly recommend filing bug reports directly through the Antigravity in-app feedback tool. You can do this by navigating to the top-right corner of the interface, clicking the Feedback icon, and selecting Report Issue.
Thanks. I’ve filled the bug report.
Yes, I also have Windows. That’s why I came here when I was looking for a solution to this problem, because everything worked before, and I’ve been struggling for several weeks to find a solution. I saw in the documentation that strict mode activates the sandbox automatically, and the sandbox is not supported in Windows, so I disabled strict mode and now the agent works with the console again.
I just logged in to like, this helped me
I tried the same settings but did not work. Thanks for the inputs.
Refreee, do something. I’ve been facing this problem for a week now. Turning off Strict Mode that didnt work for me.
I also think everyone should just relax and wait for the officials to fix the major bug.
Since I use a lot of PowerShell commands in my work, I have to paste the AI-generated commands into PowerShell, run them, and then report the process and results back to the AI. This means I have to stay and watch the AI run, and I can’t leave AG to do other tasks like Photoshop or Illustrator.
The only real pain point is that this ends up extending my total working hours. If that’s the case, then I might as well extend the project timeline too. 
Still running into this issue. Anyone heard anything new?
Just ran into this problem and found this thread.
One minute it was working fine, then I restarted my PC and it no longer worked.
In my case, antigravity was trying to run a wsl command and failing where it succeeded before.
What finally fixed it for me was adding it here:
Yellow was already there, didn’t work
I added the green, started working. Didn’t even have to restart IDE, PC, WSL, nothing.
If folks are still having trouble try adding the command it is trying to run in that green section, see if it helps.
given fixes allows the AI out of sandbox?
What We Attempted:
-
Subshell & Shell Wrapper Redirection: Wrapped command calls inside
powershell.exe -Command "..."andcmd.exe /c "...". -
File Handle Redirection: Attempted redirecting standard output/error to temporary workspace files (
out.log) to bypass console handles. -
Script Delegation: Offloaded complex steps into workspace scripts
.vscode/tasks.json tasks.
Why There Is No In-Workspace Workaround for run_command:
The failure occurs inside the native process spawner of antigravity.exe before any child process starts. When antigravity.exe prepares the Win32 STARTUPINFO structure for process creation, it attempts to open a handle to NUL requesting WRITE_DAC / WRITE_OWNER (ACL write modification rights). Because Windows kernel security rejects security descriptor write access on \Device\Null, handle creation fails immediately inside antigravity.exe, preventing any shell or command from ever launching.
The bug can only be resolved inside antigravity.exe by changing its process spawner to open NUL using standard GENERIC_WRITE file access.
==================================================================
Feature: Antigravity IDE Subprocess Execution Sandbox Output Redirection
As an AI assistant running tasks within Antigravity IDE
I want tool executions to redirect standard output streams cleanly without ACL write errors
So that background tasks, build scripts, and diagnostic commands execute successfully inside the security sandbox
Scenario: Run command in Windows environment fails with NUL write ACL error
Given Antigravity IDE is running on Windows OS with sandboxed process security active
When the assistant attempts to execute a tool via run_command
Then the process spawner encounters CORTEX_STEP_TYPE_RUN_COMMAND: opening NUL for ACL write: Access is denied
And process execution fails before the child shell is spawned
Technical Details & Root Cause:
- Binary/Host: antigravity-ide.exe (Cortex agent runner module)
- Failing Operation: CreateFileW open on device \.\NUL with write ACL permissions during subprocess handle creation
- Affected Scope: ALL tool executions dispatched via CORTEX_STEP_TYPE_RUN_COMMAND (powershell, cmd, bash, python, gradlew, adb, agy)
- Pre-flight Hook Behavior: The failure occurs inside the parent application binary (antigravity-ide.exe) prior to child process creation. No child shell arguments (> nul 2>&1), env overrides (TMP/TEMP/CORTEX_NO_NUL_REDIRECT), or script wrappers bypass the parent CreateFileW call.
- Verification: Direct execution in external user terminal succeeds natively without triggering \.\NUL ACL errors.
- Suggested Fix: Transition host agent process spawner stdio redirection from direct CreateFileW write locks on \.\NUL to virtualized pipes or ConPTY pseudo-terminal handles.