First, my own frustration. Antigravity was a power-platform that rivaled Cursor & Hermes Agent now it’s a cheap knock-off of Claude cowork. Who was the idiot who thought that ppl who actually code wanted a worse UI with more of the assistant look instead of being able to work with the machine through the IDE. This is a new version and there should be support for actual users who are doing proper work back to the IDE. I cant even give the thing allow all on ssh to continue doing the server work, If im gonna babysit it each minute, why am I not gonna hire a human and give you all this money as an Ultra user.
Now the robots complaints:
Antigravity Product Feedback: SSH Permission Gate
From: Power user managing live trading infrastructure
Date: 2026-05-21
Severity: Workflow-breaking for infrastructure-heavy users
Component: Command approval system / permission grants
The Problem
Every SSH command executed through Antigravity requires manual per-execution approval (“Yes, allow this time”). There is no mechanism to grant persistent or session-scoped SSH access to a known host.
For users managing live production infrastructure — servers, trading systems, monitoring — this turns Antigravity from a powerful orchestration tool into a click-farming exercise.
What It Looks Like in Practice
ssh -o ConnectTimeout=15 -p 2222 root@68.183.71.190 "systemctl status vv-daemon"
-> 
Allow running this command? [Yes, allow this time] [No]
ssh -o ConnectTimeout=15 -p 2222 root@68.183… “journalctl -u vv-daemon --since ‘1 hour ago’”
-> Allow running this command? [Yes, allow this time] [No]
ssh -o ConnectTimeout=15 -p 2222 root@68.183… “free -h && df -h”
-> Allow running this command? [Yes, allow this time] [No]
Three commands. Three approval clicks. Three context switches. And this is a light session — real infrastructure debugging can involve 10-20 SSH invocations.
Why Bundling Isn’t a Real Solution
Yes, you can bundle multiple commands into one SSH call. But:
-
Debugging is inherently iterative — you check something, then decide what to check next
-
The agent needs to see output before composing the next command
-
One-shot scripts miss the entire value of having an AI reason about remote system state
The agent’s strength is its ability to chain observations into actions. The approval gate breaks that chain at every link.
The Impact
CAUTION
This makes Antigravity actively worse than a plain terminal for the #1 use case of AI-assisted DevOps: managing remote infrastructure.
-
Kills flow state — constant modal interruptions while managing live systems
-
Negates agent autonomy — the agent can’t execute a multi-step diagnostic without babysitting
-
Pushes users to their terminal — if I have to approve every command anyway, why not just type it myself?
-
Comparison to competitors — other AI coding tools allow SSH with session or host-scoped trust. This feels like a regression.
Proposed Solution: Tiered SSH Trust
Option A: Host-scoped persistent permission (Preferred)
Allow ask_permission to grant SSH access scoped to a specific host:
Action: command
Target: ssh root@68.183.71.190
Scope: persistent (or session)
This is no less secure than granting persistent access to git push or npm run — both of which execute arbitrary code. SSH to a user-owned host with key-based auth is arguably more secure than curl | bash patterns.
Option B: Session-scoped SSH grant
At the start of a conversation, if the user approves SSH to a host once, it’s trusted for the remainder of that session. No persistence across sessions.
Option C: SSH allowlist in user config
Let users define trusted hosts in their Antigravity config:
json
{
“trusted_ssh_hosts”: [
“root@68.183.71.190:2222”,
“deploy@…”
]
}
Commands targeting these hosts skip the approval modal.
The Principle
The security model should protect users from unintended actions, not from repeated intentional ones.
If I’ve approved SSH to 68.183.71.190 five times in a row, the sixth approval isn’t adding security — it’s adding friction. The threat model hasn’t changed. The user’s intent hasn’t changed. Only their patience has.
Summary
| Current State | Desired State |
|---|---|
| Every SSH requires click approval | First SSH requires approval, then host is trusted |
No SSH in ask_permission targets |
SSH allowed with host-scoped targets |
| Agent can’t chain remote diagnostics | Agent can autonomously debug remote systems |
| Power users forced back to terminal | Power users stay in Antigravity for orchestration |