Always Proceed" Terminal Command Setting Has No Effect

Google Antigravity
,
1

Bug Report: “Always Proceed” Terminal Setting Has No Effect on Command Approval

Product: Antigravity IDE
Version: Installed at C:\Users\<USERNAME>\AppData\Local\Programs\Antigravity
OS: Windows 11 Pro (x64)
Date: 2026-02-28

Summary

The “Terminal Command Auto Execution” setting has no effect. When set to “Always Proceed” with an empty Deny List and * in the Allow List, the agent is still prompted for manual approval on every terminal command. The setting UI accepts and saves the configuration, but the command execution pipeline does not read or honor it.

Steps to Reproduce

  1. Open Settings → Agent in Antigravity

  2. Set Terminal Command Auto Execution to “Always Proceed”

  3. Confirm Deny List Terminal Commands is empty

  4. Add * to Allow List Terminal Commands

  5. Start a new conversation (settings note says changes apply to new messages)

  6. Ask the agent to run any command (e.g., Get-ComputerInfo)

  7. Expected: Command auto-executes without prompting

  8. Actual: User is prompted to click “Run” for every command

Root Cause Analysis (Source Code Investigation)

The Antigravity application source was examined at:

  • resources/app/out/main.js (~7.6 MB, minified Electron main process)

  • resources/app/out/jetskiAgent/main.js (~10.7 MB, minified agent logic)

Finding 1: SafeToAutoRun Does Not Exist in Application Code

The LLM tool schema defines a parameter called SafeToAutoRun on the run_command tool. This parameter is what the AI agent sets to true or false to signal whether a command is safe.

However, SafeToAutoRun, safeToAutoRun, and safe_to_auto_run return zero matches in both

main.js and

jetskiAgent/main.js. The application never reads this flag. The AI agent faithfully sets it, but Antigravity ignores it entirely.

Finding 2: run_command Does Not Exist in Agent Module

The string run_command returns zero matches in

jetskiAgent/main.js. The agent module doesn’t reference the tool by this name, suggesting the tool invocation is handled by a different layer that may strip or transform tool metadata before evaluating approval.

Finding 3: Allow List Setting Is Not Read by Command Execution Logic

Searching for allowList, allow_list, userAllowlist, and USER_ALLOWLIST in

main.js:

  • Generic ALLOWLIST appears in unrelated contexts (Node crash reporter, environment variables)

  • userAllowlist and USER_ALLOWLIST return zero matches

  • The settings UI writes allow-list entries to

    user_settings.pb (protobuf), but the command execution pipeline never reads them back

Finding 4: Approval Decision Functions Don’t Exist

Standard function names for approval logic were searched:

  • shouldAutoExecute → 0 matches

  • shouldAutoRun → 0 matches

  • needsApproval → 0 matches

  • requiresApproval → 0 matches

  • commandNeedsApproval → 0 matches

  • shouldPrompt → 0 matches

There is no function that evaluates whether a command should be auto-approved based on user settings.

Finding 5: Enum Exists But Is Disconnected

The settings UI uses an enum (minified as Lx) with a value like Lx.AUTO (label: “Agent Decides”). The “Always Proceed” option exists in the UI, but the corresponding code path that should bypass the approval dialog appears to be missing or non-functional.

Finding 6: Approval Appears Hardcoded

The strings "Manually proceeded." and "by agent." exist in the approval flow, alongside isTurboReviewMode and artifactReviewPolicy. These suggest the approval system is primarily designed for artifact/file reviews, not terminal commands. The terminal command approval may have been added to the settings UI without a corresponding implementation in the command execution pipeline.

Architecture Diagram

┌─────────────────────┐     ┌──────────────────────────┐

│ LLM Tool Schema │ │ Antigravity Settings │

│ │ │ UI │

│ SafeToAutoRun:true ──► │ “Always Proceed” ✓ │

│ (set by AI agent) │ ✗ │ Allow List: * │

│ │ │ │ Deny List: (empty) │

└─────────┬───────────┘ │ └──────────┬───────────────┘

      │              │             │

      │ IGNORED      │ DISCONNECTED│ Writes to

      │              │             │ user_settings.pb

      ▼              │             ▼

┌─────────────────────┐ │ ┌──────────────────────────┐

│ Command Execution │ │ │ user_settings.pb │

│ Pipeline │ │ │ (protobuf binary) │

│ │ │ │ │

│ ► ALWAYS shows │◄─┘ │ Never read by │

│ approval dialog │ │ command pipeline │

│ ► No conditional │ │ │

│ bypass logic │ │ │

└─────────────────────┘ └──────────────────────────┘

Impact

  • Severity: Medium-High (usability)

  • Users cannot leave the agent to work autonomously, requiring constant babysitting

  • The setting exists and appears functional in the UI, creating a false expectation

  • Competitive disadvantage vs. Cursor, which respects auto-approval settings

  • Breaks the documented workflow annotation // turbo-all for hands-off execution

Expected Fix

  1. The command execution pipeline should read the SafeToAutoRun flag from the tool invocation

  2. The pipeline should read the Terminal Command Auto Execution setting from

    user_settings.pb

  3. When set to “Always Proceed” (and command is not in the Deny List), the approval dialog should be bypassed

  4. The Allow List * wildcard should be interpreted as “match all commands”

Environment Details

Component Detail
Antigravity Install C:\Users\<USERNAME>\AppData\Local\Programs\Antigravity
Settings File C:\Users\<USERNAME>\.gemini\antigravity\user_settings.pb
Agent Bundle resources/app/out/jetskiAgent/main.js (10.7 MB)
Main Process resources/app/out/main.js (7.6 MB)
Shell PowerShell (Windows 11 Pro)
2

Hi! There is a fix: GitHub - Kanezal/better-antigravity: The repository was created to support Antigravity from the community.

Leave a star if it helped you :slight_smile:

3

Thank you for bringing the issue to our attention. Our engineering team is currently investigating the matter, and we appreciate your patience as we work toward a resolution.