[Bug] Smart App Control blocks vscode-policy-watcher.node — "Part of this app was blocked" (Windows 11, IDE 2.5.5)

Google Antigravity
1

Summary

On Windows 11 with Smart App Control enabled, Windows Security shows “Part of this app was blocked” for Antigravity IDE, naming the bundled native module vscode-policy-watcher.node. The IDE failed to start or some features would not initialize.

Root cause is confirmed: the native module shipped inside Antigravity IDE is not Authenticode-signed, so Smart App Control blocks it. I have a working local workaround, but it is not something normal users should have to do — the real fix has to happen in the release pipeline.

Environment

  • OS: Windows 11, Smart App Control: On
  • Antigravity IDE: 2.5.5 (verified as VS Code 1.107 / Electron 39.2.3 base)
  • Security: Microsoft Defender + Avast

Root cause 1 — unsigned native module

Windows Code Integrity logged Event IDs 3033 and 3077 for:

%LOCALAPPDATA%\Programs\Antigravity IDE\resources\app\node_modules\@vscode\policy-watcher\build\Release\vscode-policy-watcher.node

I compared this against the official Microsoft VS Code package built on the same base (1.107 / Electron 39.2.3). The corresponding file there:

  • carries a Microsoft Authenticode signature,
  • verifies as Valid via Get-AuthenticodeSignature,
  • passes a Microsoft Defender custom scan,
  • exposes an identical JavaScript entry interface to the file shipped in Antigravity.

So the same upstream module is signed in VS Code and unsigned in Antigravity. This looks like a gap in the Antigravity build/signing step rather than an upstream problem.

Workaround applied (local, not a supported fix)

  1. Fully quit Antigravity IDE.
  2. Backed up the unsigned original in place as .bak.
  3. Replaced it with the Microsoft-signed counterpart from the same VS Code / Electron base.
  4. Restarted the IDE.
  5. Verified no new vscode-policy-watcher.node Code Integrity block was raised and that the IDE process was responsive.

Result: Smart App Control stayed ON, the block stopped, and the IDE launched.

Root cause 2 — Node TLS chain vs. antivirus HTTPS inspection

After the first fix, sign-in failed with unable to verify the first certificate in the network logs.

Avast Web/Mail Shield inspects HTTPS using its own local root CA. Clients that read the Windows certificate store validated the chain fine; Antigravity’s bundled Node 22 runtime, using its default baked-in CA bundle, did not.

Verification steps:

  1. TLS to the Google OAuth endpoint from a Windows-store-aware client → success.
  2. Same request from Node with default CAs → certificate chain error reproduced.
  3. Same request from Node using the Windows system certificate store → success.
  4. Narrow persistent fix: pointed Node at the existing Avast CA file via a user-level variable.
    • NODE_EXTRA_CA_CERTS = C:\ProgramData\Avast Software\Avast\wscert.pem

After restart, authentication state became success / signedIn.

Product suggestion: have the bundled Node/Electron runtime use the OS certificate store by default (e.g. --use-system-ca), or surface a supported setting for an extra CA bundle. Any user behind corporate TLS inspection or a consumer AV that inspects HTTPS will hit this, and the error message gives no hint about what to do.

Verification checklist

  • IDE window opens and is responsive
  • Blocked policy-watcher component is now Microsoft-signed
  • Smart App Control left ON
  • TLS verification left ON
  • Google sign-in succeeds
  • Original file backed up for rollback

Explicitly not used, because they disable protections rather than fix the cause: turning off Smart App Control, blanket Defender exclusions, NODE_TLS_REJECT_UNAUTHORIZED=0, --ignore-certificate-errors.

Caveats with this workaround

  • An Antigravity update will likely overwrite the replaced file with the unsigned version again, and the warning will return.
  • There may be other unsigned .node binaries in the package. If the terminal or another feature gets blocked, the Code Integrity event names the exact file — that specific file should be targeted rather than switching off security layers.
  • If the AV also inspects localhost HTTPS, language-server logs can show TLS handshake failures. A Web Guard exception limited to localhost / 127.0.0.1 is safer than disabling HTTPS scanning system-wide.

Rollback

  1. Quit Antigravity IDE.
  2. Remove the replaced vscode-policy-watcher.node.
  3. Restore the adjacent .bak to its original name.
  4. Remove the user-level NODE_EXTRA_CA_CERTS variable if no longer wanted.

What I’d ask from the team

  1. Authenticode-sign every bundled .node, .dll and .exe in the installed tree with the production certificate, and gate releases on a Get-AuthenticodeSignature check in CI.
  2. Consider using the OS certificate store for the bundled runtime’s TLS, or document a supported extra-CA setting.

Likely related reports (same signing root cause, different binary):

  • “Antigravity stuck on loading - chat doesnt loads” — Smart App Control blocking language_server_windows_x64.exe
  • “Antigravity stuck at loading agent” — Defender blocking the same language server

Those threads were resolved by turning Smart App Control off or adding an AV exclusion, which is not acceptable on a managed device. Signing the binaries would fix all of these at once.

Diagnostics anyone can run:

Get-ChildItem "$env:LOCALAPPDATA\Programs\Antigravity IDE" -Recurse -Include *.node,*.dll,*.exe -ErrorAction SilentlyContinue |
  Get-AuthenticodeSignature |
  Where-Object Status -ne 'Valid' |
  Select-Object Status, Path |
  Format-Table -AutoSize

Event Viewer → Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational (Event ID 3033 / 3076 / 3077).

Windows ARM64: Smart App Control blocks Antigravity IDE 2.5.5 entirely (Antigravity IDE.exe is unsigned)