When Antivirus Blocks Antigravity's Launch, Verify the Signature Before You Allow It

macOS: verify Gatekeeper and quarantine before you clear them

On macOS, a downloaded app carries a com.apple.quarantine extended attribute, and Gatekeeper evaluates the signature and notarization on first launch. When launching goes silent, start by checking whether that evaluation failed.

# 1. Is the quarantine attribute present? (if so, it's subject to the first-launch gate)
xattr -p com.apple.quarantine /Applications/Antigravity.app
 
# 2. Verify signature integrity (fails non-zero if tampered or incompletely signed)
codesign --verify --deep --strict --verbose=2 /Applications/Antigravity.app
 
# 3. See Gatekeeper's verdict in human-readable form (prints the reason for a rejection)
spctl -a -t exec -vvv /Applications/Antigravity.app
 
# 4. Confirm WHO signed it (this is the part that matters most)
codesign -dv --verbose=4 /Applications/Antigravity.app 2>&1 | grep -E "Authority|TeamIdentifier"

In that fourth output, check by eye that the Authority and TeamIdentifier match the values the distributor publishes. This is the crux: passing codesign --verify only proves the app is correctly signed. Whether the correct party signed it is something you can only assert after matching the signer's identity yourself. Cross-check against the Team ID listed on the official download page; if it doesn't match, treat that as a real warning, not a false positive.

Only once the identity matches and verification passes do you clear the quarantine attribute.

# Recursively remove the quarantine attribute under the app (run this AFTER verifying)
sudo xattr -dr com.apple.quarantine /Applications/Antigravity.app

The r in -dr means recursive, d means delete. An app bundle contains many executables, so clearing only the top level can still get blocked by a helper inside. That's why you clear recursively. Conversely, running this on an app you haven't verified is equivalent to disabling Gatekeeper wholesale — so never skip the order.

Windows: confirm the signature, then allow with the narrowest scope

On Windows, a downloaded file carries a "Zone.Identifier" alternate data stream, and SmartScreen holds execution. Microsoft Defender's behavioral detection often stacks on top. Open PowerShell as administrator and check in order.

# 1. Does it carry the downloaded-from-internet block flag?
Get-Item "$env:USERPROFILE\Downloads\AntigravitySetup.exe" -Stream Zone.Identifier -ErrorAction SilentlyContinue
 
# 2. Verify the Authenticode signature state (anything other than Valid needs attention)
Get-AuthenticodeSignature "C:\Program Files\Antigravity\Antigravity.exe" |
  Format-List Status, StatusMessage, SignerCertificate
 
# 3. Show the signer's Subject (match it against the distributor)
(Get-AuthenticodeSignature "C:\Program Files\Antigravity\Antigravity.exe").SignerCertificate.Subject

If the second Status is HashMismatch rather than Valid, the file changed after it was signed. That's not a false positive — it's a sign of corruption or tampering. Start over with a fresh download. Only when Status is Valid and the third Subject matches the published publisher do you proceed to allow it.

# Clear the block flag (on the installer itself)
Unblock-File "$env:USERPROFILE\Downloads\AntigravitySetup.exe"
 
# Scope the Defender exclusion to a PROCESS, not the whole folder
Add-MpPreference -ExclusionProcess "Antigravity.exe"

Many guides tell you to exclude the whole folder with something like Add-MpPreference -ExclusionPath "C:\Program Files\Antigravity". I avoid that. A folder exclusion also leaves any other executable later dropped into that folder unscanned. Narrowing to a process name (-ExclusionProcess) removes only the target executable from scanning. The narrower the exclusion, the safer — and I keep that principle here too.

Operating in a corporate environment where you can't add exceptions

On a company-issued machine, an EDR (Endpoint Detection and Response) agent is centrally managed, and both Add-MpPreference and xattr may be blocked by policy. Hunting for a personal workaround here is the wrong call.

Instead, assemble what you hand to IT. What they need isn't "it won't run, please fix it" — it's verified facts: the output of codesign -dv or Get-AuthenticodeSignature (the signer's identity and verification status), the official distributor URL, and a minimal-scope proposal ("a process-level allowance is enough"). With those three in hand, an admin can re-verify legitimacy themselves and add the smallest safe exception.

As an indie developer who also runs the operations side of an art practice, I touch machines managed by different owners depending on context. What I learned there: bringing "evidence of verification" gets you through faster than bringing "steps to bypass." With evidence, the conversation becomes a requirements check; without it, it becomes an argument.

Fold the verification into one script so it doesn't recur

Dealing with the same false positive separately across Macs and Windows boxes, one machine at a time, lets the procedure drift into personal habit. At one point I had three Macs with subtly different "de-quarantine notes," and later realized one of them skipped the signature check entirely. That "cut a corner on just one machine" state is the dangerous one.

The fix is simple: fold verification and clearing into one script, and enforce in code that you don't proceed to clearing unless verification passes.

#!/usr/bin/env bash
# verify-then-allow.sh — clear quarantine only when signature verification passes (macOS)
set -euo pipefail
 
APP="/Applications/Antigravity.app"
EXPECTED_TEAM_ID="XXXXXXXXXX"   # replace with the Team ID published on the official page
 
echo "> Verifying signature integrity..."
codesign --verify --deep --strict "$APP"
 
echo "> Matching the signer's Team ID..."
ACTUAL=$(codesign -dv --verbose=4 "$APP" 2>&1 | awk -F= '/TeamIdentifier/{print $2}')
if [ "$ACTUAL" != "$EXPECTED_TEAM_ID" ]; then
  echo "x Team ID mismatch (got: ${ACTUAL:-none}). Treating this as a real warning, not a false positive."
  exit 1
fi
 
echo "> Checking Gatekeeper's verdict..."
spctl -a -t exec -vv "$APP"
 
echo "OK Verification passed. Removing quarantine attribute."
sudo xattr -dr com.apple.quarantine "$APP"
echo "OK Done."

The point of this script isn't convenience — it's fixing the order in place. With set -euo pipefail, if any single step fails, nothing after it runs. If the Team ID doesn't match, exit 1 stops it, and you never reach de-quarantine. In other words, it erases the option to "skip the check because it's tedious" from the start. When you set up a new machine, carrying this one file keeps verification quality from drifting between boxes. It's the same idea as syncing settings across multiple Macs.

The one step you should never automate is replacing EXPECTED_TEAM_ID with the real value. If you auto-fetch it, you end up trusting "what the currently downloaded binary claims" rather than "who actually signed it," and the verification loses its meaning. A human matches it against the official page and fills it in once — that friction is exactly where this script's safety comes from.

What to do next if you're stuck

If you're locked out of launch right now, check your OS, run commands 1 through 4 from the matching section in order, and look at just one thing: whether Authority / Subject matches the distributor's published value. If it matches, you can safely allow it as a false positive; if it doesn't, go back to a fresh download. The decision collapses to that single point.

If launch actually succeeds but the app feels sluggish, the cause is elsewhere. In that case, triaging when Antigravity runs slow or measuring CLI startup latency with hyperfine will serve you better.

Living with antivirus becomes unavoidable the faster you iterate with dev tools. I still stumble in small ways machine to machine, but as long as I hold the order — verify, then allow — at least I never punch the hole myself.