Windows Antigravity 2.0: bounded unattended subagents plus explicit cross-model child delegation?

Google Antigravity
1

We previously stopped evaluating Antigravity for a local multi-agent workflow because two requirements were not satisfied: (1) bounded unattended continuation without repeated owner approvals, and (2) deliberate parent→child delegation to a different model family. Current Antigravity 2.0 docs now describe asynchronous/custom subagents, commandExecutionPolicy, inter-agent messaging, and per-subagent model tiers. However, the newer fine-grained permission engine is documented as unavailable on Windows, and the subagent model selector documents tiers rather than an explicit model-family selector. On Windows, is there a supported configuration that allows workspace-scoped subagents to continue unattended under bounded permissions without unrestricted Turbo/full-filesystem access? Separately, can a parent explicitly invoke a child on a different model family (for example Gemini parent → Claude child), or only choose a tier within the same model family? If either is unsupported, is there a roadmap/tracking item or recommended safe pattern?

2

Hi @John_S2,

1. Unattended subagents on Windows: the terminal sandbox isn’t on Windows yet, but you can still keep subagents bounded without Turbo:

  • Leave “Non-Workspace File Access” off, so file tools stay inside the workspace.
  • For subagents that don’t need the terminal, create a custom one in .agents/agents/<name>.md and leave run_command out of its tools: list.
  • If a subagent needs commands like pytest or npm test, add just those to your Terminal Command Allowlist. Everything else will still ask for approval.
  • For full OS-level sandboxing, run the workspace in WSL2.

2. Different model family: subagents only choose a tier (inherit, flash-lite, flash, pro).

  • If your main agent runs on Claude, inherit keeps subagents on Claude, and flash or pro sends them to Gemini.
  • A Gemini parent can’t start a Claude child yet. As a workaround, the CLI lets you pick a model directly: agy --model "<model-id>" -p "<prompt>". Run agy models to see the IDs.

We’ve logged explicit model selection for subagents as a feature request.

3

Thanks again for the earlier guidance. We now have the Antigravity CLI running on Windows and have reached a more specific blocker that we have not been able to resolve from the official documentation.

Environment / settings:

  • Antigravity CLI 1.2.15

  • Windows x64

  • enableTerminalSandbox=true

  • toolPermission=proceed-in-sandbox

  • launched with --sandbox

  • no paid-credit fallback

  • disposable workspace only

We first asked the agent to perform a benign in-workspace PowerShell write/read:

Set-Content -Path sandbox-write.txt -Value "POC_OK"; Get-Content -Path sandbox-write.txt

The command never executed. Headless mode returned a denied action:

escalate_admin()

with display_name: Bash, an empty target, and stderr indicating the permission could not be prompted for in headless mode.

To remove PowerShell, file I/O, and command chaining as variables, we then tested only:

cmd.exe /d /c echo POC_DIAGNOSTIC

through the same sandboxed run_command path.

The exact same result occurred: escalate_admin() was requested before successful shell execution.

We have not granted that permission, disabled the sandbox, used dangerously-skip-permissions, switched to Always Proceed, or broadened filesystem access.

The current official documentation says that on Windows, Proceed in Sandbox should allow commands that can run inside the Terminal Sandbox without approval, while commands requiring escape should require review. The CLI sandbox documentation identifies Windows isolation as AppContainer.

Could someone from the Antigravity team clarify what escalate_admin() means in this situation?

Specifically:

  1. What exact Windows capability/resource does escalate_admin() grant?

  2. Does granting it cause the command to run outside AppContainer/sandbox isolation?

  3. Is it a one-time AppContainer provisioning/setup permission or a recurring execution permission?

  4. Does it grant Windows administrator/full-machine capability?

  5. Why would a trivial workspace-only cmd.exe /c echo command require it when Proceed in Sandbox is enabled?

  6. Is there a documented configuration or initialization step we are missing?

  7. Is this a known Windows CLI 1.2.15 limitation or bug?

Our goal is bounded unattended execution: commands inside the workspace should run automatically in AppContainer, while anything requiring sandbox escape must remain blocked or require explicit approval.

We do not want to whitelist escalate_admin() until its scope and sandbox implications are clearly understood.

Thanks.