[Feedback/Bug] Permission Implicit Coverage (write_file overriding explicit read_file) & Endless Spinning UI Bug

Google Antigravity
, , ,
1

Hi team, I’ve encountered two friction points regarding the Agent Permissions system in the Antigravity IDE while trying to configure the agent to stop automatically editing files. I would appreciate it if you could take a look:

1. The write_file Implicit Coverage overriding explicit Always Allow Rules

  • Use Case: I want to allow the Agent to dynamically read files to gather context (by explicitly placing read_file(/path) in Always Allow), but I want to stop it from automatically modifying files (by placing write_file(/path) in Always Ask).

  • Current Behavior: According to the documentation, write_file implicitly covers read_file for the same path. Unfortunately, this means the ‘Always Ask’ status of my write rule forces all simple read operations to also trigger the approval prompt, overriding my explicit read_file rule in ‘Always Allow’. The agent is currently unable to read context automatically without firing constant prompts.

  • Feature Request: Please decouple this implicit permission fallback, or update the rule precedence logic: an explicitly defined read_file entry in ‘Always Allow’ should have higher priority than the implicit read constraint inherited from a write_file rule.

2. Missing Allow/Deny buttons & Endless Spinning UI Bug for Artifacts

  • Whenever the Agent requests to edit certain IDE artifacts (such as the Implementation Plan), the permission Approval UI fails to render correctly.

  • Instead of showing the standard Allow / Deny buttons, the UI gets stuck in an endless loading state with a spinning cursor icon next to “Editing Implementation Plan” (see attached screenshot). Because the buttons don’t load, I’m unable to approve or deny the action and the task gets stuck.

Would love to see these usability quirks addressed in an upcoming patch. Thanks!

image
image900×248 54.1 KB

2

I’m hitting the same “Missing Allow/Deny buttons” bug, but with a different trigger.

In my case, the UI gets stuck on “Waiting for user input” (with no Allow/Deny buttons rendered) when the agent uses grep_search or view_file to access files outside the current workspace (e.g., sibling repos at ../other-project/).

Steps to reproduce:

  1. Open a workspace (e.g., ~/dev/project-a/)
  2. Ask the agent a question that requires reading files from a sibling directory (e.g., ~/dev/project-b/)
  3. The agent calls grep_search or view_file targeting the external path
  4. The UI shows “Searching [pattern]” with a spinner and “Waiting for user input” — but no Deny / Allow in Workspace buttons appear
  5. The operation hangs until it times out with context canceled

Environment:

  • macOS
  • Antigravity IDE (latest as of 2026-05-12)
  • Claude Opus 4.6 (Thinking) model