feat: add autonomous approval mode for Antigravity

[eXPerience83]

Summary

Add a first-class Antigravity approval mode that matches the existing Remote Dev Codex UX: a managed autonomous|guarded launch policy, defaulting to autonomous, while preserving the hardened outer-container and project/Git boundaries.

The implementation must remain launch-scoped where the upstream CLI permits it. Remote Dev must not weaken Docker/TrueNAS isolation, enable the unusable nested Antigravity sandbox, or take ownership of unrelated vendor settings.

Dependency status

Implementation gates are satisfied:

• security: harden outer containers and add cross-service isolation canaries #42 / PR security: harden role containers and prove isolation #155 — hardened Antigravity container/state topology.
• test: Antigravity runtime fixture reports host installation instead of reviewed fixture #149 / PR test: isolate Antigravity runtime fixtures from host tools #160 — deterministic Antigravity runtime fixtures.
• perf: benchmark and split Antigravity launch integrity verification #153 / PR perf: split Antigravity launch integrity verification #161 — lightweight status vs explicit/full runtime verification.
• P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213 / PR fix: enforce project-collection Git boundary #214 — project-collection Git boundary and deleted-cwd lifecycle.
• docs/security: document Antigravity inner-sandbox baseline and ownership #215 — Antigravity nested-sandbox baseline documented and closed.

Security boundary

Autonomous approval changes only Antigravity's in-agent confirmation behavior inside resources already exposed to its role container.

Keep unchanged:

• read-only container root;
• cap_drop: [ALL] plus the reviewed Antigravity capability allowlist;
• no-new-privileges;
• private IPC and bounded PID limit;
• bounded /tmp and /run tmpfs;
• Antigravity-only workspace/state/credentials;
• no Docker socket, host root, host network or shared writable credentials;
• mandatory perf: benchmark and split Antigravity launch integrity verification #153 runtime verification before a real launch;
• completed P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213 selected-project/Git boundary;
• AGY_CLI_DISABLE_AUTO_UPDATE=true;
• existing vendor settings unrelated to the managed approval mode.

Approval prompts are not an isolation boundary. The supported security boundary remains the hardened outer role container plus the completed project/Git boundary.

Nested sandbox baseline

Controlled TrueNAS validation already established that the Antigravity terminal sandbox is not usable under the supported hardened profile without weakening the outer container. #215 records that evidence.

Therefore #159 must not:

• add --sandbox automatically;
• enable or persist enableTerminalSandbox;
• depend on toolPermission=proceed-in-sandbox;
• persist sandbox-bypass authorization;
• add privileged, SYS_ADMIN, unconfined profiles, host namespaces or similar relaxations.

2026-09-10 live Antigravity 1.1.28 validation

All approval-mode research below was performed on the real hardened TrueNAS Antigravity role using Antigravity CLI 1.1.28, without changing the container image/hardening.

Baseline guarded behavior

A normal managed launch prompted even for harmless shell work such as pwd.

toolPermission=always-proceed

With only toolPermission=always-proceed, Bash/Create/Read/Edit operations completed without prompts.

Adding --mode=accept-edits did not provide additional approval autonomy; it only changed the vendor execution-mode indicator. Therefore #159 does not need to manage agentMode or force --mode=accept-edits.

Artifact review

With toolPermission=always-proceed and the default artifact policy, a plan artifact still paused for review.

Adding artifactReviewPolicy=always-proceed removed that pause.

--dangerously-skip-permissions

The documented launch-scoped flag --dangerously-skip-permissions was then tested directly:

• harmless Bash/Git/Create/Read/Edit completed without prompts;
• a --mode=plan workflow created its plan/artifacts and continued through implementation without a review stop;
• the flag did not enable the vendor sandbox;
• the flag did not persist toolPermission, artifactReviewPolicy or agentMode;
• a user-configured fine-grained permissions.deny rule still blocked the denied command;
• explicit persistent toolPermission=request-review + artifactReviewPolicy=asks-for-review still became autonomous for that launch when the flag was present;
• a later launch without the flag immediately returned to guarded prompting.

Start / Continue / return to guarded

Using a disposable project and sibling canary:

1. Start with --dangerously-skip-permissions completed shell/file/Git work without prompts.
2. --continue with the same flag resumed the same conversation and continued without prompts.
3. A later launch without the flag prompted again for pwd.
4. No approval state remained persisted.
5. The sibling canary remained unchanged.

This establishes the reviewed Antigravity 1.1.28 mapping for Remote Dev.

Chosen launch-policy architecture

Use the same Remote Dev abstraction as Codex while keeping provider-specific mechanics separate:

REMOTE_DEV_ANTIGRAVITY_APPROVAL_MODE=autonomous|guarded

Default: autonomous, matching the current Codex wrapper.

Autonomous

Remote Dev owns and injects exactly the reviewed vendor approval bypass:

--dangerously-skip-permissions

Do not also force --mode=accept-edits, --mode=plan, --sandbox, toolPermission, artifactReviewPolicy or agentMode.

Guarded

Do not inject the bypass. Use normal vendor review semantics.

Remote Dev must not silently rewrite the user's full vendor settings merely to enforce guarded mode.

If persistent vendor approval configuration makes guarded semantics impossible to guarantee, the launch must fail closed with a clear diagnostic instead of pretending to be guarded.

Provider-policy diagnostics and repair

Add a bounded, offline Antigravity policy inspection/repair path.

Diagnostics

Doctor/status may inspect only the minimum non-secret approval keys needed to determine whether guarded mode is compatible. It must not print OAuth/session data, arbitrary settings, project contents or permission-rule contents.

Expected health outcomes include:

Antigravity guarded compatibility: OK

or a clear conflict such as a persistent toolPermission=always-proceed / incompatible artifact-review policy.

Normal menu/status must remain lightweight and must not execute the vendor CLI, contact the network, or replace #153 full integrity verification.

Explicit repair

Provide an explicit repair action/command for known guarded conflicts.

Repair must:

• never run automatically during launch or Doctor;
• operate only on the canonical Antigravity-private settings.json;
• reject symlinks, non-regular files, malformed JSON and unsafe ownership/type states;
• remove/reset only the reviewed top-level approval keys that conflict with guarded behavior;
• preserve unrelated and unknown vendor settings in meaning;
• preserve fine-grained permissions.allow/ask/deny untouched;
• use an atomic same-directory write with restrictive permissions;
• never print secrets or duplicate the whole settings file into a broad backup;
• fail closed on unknown approval semantics rather than guessing.

This is aligned with the common Remote Dev principle for current/future agents: launch policy is managed by Remote Dev; persistent provider configuration remains provider/user-owned unless an explicit bounded repair is requested.

Codex does not require the same repair mechanism because its current wrapper already applies an authoritative launch-scoped approval/trust policy and rejects conflicting policy arguments/config overrides. Future agent integrations such as Claude Code should follow the same abstraction, not mechanically copy one provider's config format.

Wrapper ownership and UX

run-antigravity should mirror the current Codex policy resolver where the provider contract permits:

• accepted modes: autonomous|guarded;
• default: autonomous;
• deployment env: REMOTE_DEV_ANTIGRAVITY_APPROVAL_MODE;
• optional per-launch --approval-mode autonomous|guarded;
• --print-policy for local/offline effective-policy reporting;
• wrapper owns/rejects direct user attempts to pass --dangerously-skip-permissions and any reviewed argument that would contradict the managed approval mode;
• Start and Continue use the same resolver;
• one-launch menu override is consumed once and then resets to the configured deployment mode.

The Antigravity menu slot currently marked Launch/approval options [not available] should become the reviewed approval-mode UI analogous to Codex.

Guarded compatibility contract

Guarded compatibility should be evaluated only from the minimum reviewed persistent approval keys.

Safe/default guarded states include absent vendor defaults and the documented request/review values.

Known autonomous or otherwise incompatible values must block a managed guarded launch until the user either changes the vendor configuration or invokes the explicit repair tool.

Fine-grained user permission rules remain user-owned. Explicit deny continues to be honored in autonomous mode based on the validated 1.1.28 behavior.

Malformed/unknown approval semantics relevant to the guarded guarantee must fail closed.

Tests

Add deterministic synthetic coverage for at least:

• accepted/rejected approval-mode values;
• default autonomous;
• deployment env and per-launch override precedence;
• --print-policy remains offline/lightweight;
• autonomous argv contains exactly the managed --dangerously-skip-permissions approval bypass;
• guarded argv does not contain it;
• direct user bypass/policy overrides are rejected;
• Start and Continue share the same resolver;
• one-launch menu override is consumed once;
• guarded compatibility detection for absent/default/request-review settings;
• guarded conflict detection for known incompatible values;
• malformed/symlink/non-regular settings fail closed where required;
• explicit repair changes only reviewed conflicting top-level approval keys;
• unrelated/unknown settings and fine-grained permission rules are preserved;
• no automatic settings mutation during launch/status/Doctor;
• no --mode=accept-edits or --sandbox is injected;
• perf: benchmark and split Antigravity launch integrity verification #153 status/verify behavior remains unchanged;
• P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213 project/Git boundary remains unchanged;
• Compose hardening/mount topology remains unchanged;
• no network/update merely to resolve/display approval mode.

Use synthetic credentials/state only; CI must not require a Google account.

TrueNAS acceptance

After CI/review, validate one exact candidate/image on TrueNAS:

1. verify exact source/image/runtime identity;
2. confirm security: harden outer containers and add cross-service isolation canaries #42 hardening and P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213 boundary remain effective;
3. confirm configured/default autonomous mode is reported correctly;
4. Start Antigravity in a disposable project and confirm harmless shell/file/test/Git work runs without prompts;
5. Continue latest conversation and confirm the same effective autonomous mode;
6. use a one-launch guarded override and confirm prompts return;
7. introduce a synthetic known persistent guarded conflict, confirm diagnostics detect it and managed guarded launch fails closed;
8. invoke explicit repair, confirm only reviewed approval keys are repaired and unrelated settings remain unchanged;
9. confirm autonomous still respects an explicit fine-grained deny rule;
10. confirm no sandbox/bypass persistence or outer-container weakening;
11. confirm real launch still performs mandatory perf: benchmark and split Antigravity launch integrity verification #153 verification while ordinary menu/status remains lightweight;
12. confirm sibling canaries remain untouched.

Out of scope

• weakening/reopening security: harden outer containers and add cross-service isolation canaries #42 hardening;
• reimplementing P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213;
• enabling/fixing Antigravity's nested sandbox (docs/security: document Antigravity inner-sandbox baseline and ownership #215 records the current baseline);
• fix: move development temp/cache workloads off bounded /tmp tmpfs #158 temp/cache scratch behavior;
• automation: review official Antigravity CLI updates without gating availability #83 vendor-review automation;
• changing Antigravity install/admission policy;
• redesigning perf: benchmark and split Antigravity launch integrity verification #153 verification;
• broad workspace/credential sharing;
• forcing provider-specific config ownership merely for cross-agent cosmetic symmetry.

Relationships

• security: harden outer containers and add cross-service isolation canaries #42 / PR security: harden role containers and prove isolation #155 — outer-container hardening baseline.
• perf: benchmark and split Antigravity launch integrity verification #153 / PR perf: split Antigravity launch integrity verification #161 — status/verify/pre-launch integrity contract.
• P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213 / PR fix: enforce project-collection Git boundary #214 — project collection/Git boundary.
• docs/security: document Antigravity inner-sandbox baseline and ownership #215 — documented/closed Antigravity nested-sandbox baseline.
• ux: rename "Open a login shell" to "Open container shell" across agent roles #220 — separate UX issue renaming Open a login shell to Open container shell; do not mix that text-only change into feat: add autonomous approval mode for Antigravity #159.

Current implementation direction

Proceed with the launch-scoped 1.1.28 mapping proven above:

autonomous -> managed --dangerously-skip-permissions
guarded    -> normal vendor review semantics, with fail-closed compatibility check

Add offline diagnostics plus explicit bounded repair for persistent guarded conflicts. Do not persist Remote Dev-owned approval defaults into the vendor settings file.

[eXPerience83]

2026-08-27 — upstream permission-contract research: first-class autonomous settings exist

Current official Antigravity CLI documentation now answers the main research question in this issue: there is a documented first-class permission/autonomy contract, so Remote Dev should not start from undocumented flags or blindly rewrite arbitrary settings.

Official persistent permission settings

Google documents ~/.gemini/antigravity-cli/settings.json with these relevant keys:

• toolPermission
  • request-review — default; prompts for write/bash/web tools
  • proceed-in-sandbox — auto-proceeds when sandboxed
  • strict — prompts for all non-read tools
  • always-proceed — runs all tools without prompting; documented as highest risk
• artifactReviewPolicy
  • asks-for-review — default
  • agent-decides
  • always-proceed — never pauses for artifact/code review
• allowNonWorkspaceAccess — default off; keep this safety boundary unchanged unless a separate reviewed requirement says otherwise
• enableTerminalSandbox — vendor inner-sandbox setting; do not conflate this with Remote Dev's already-completed outer-container isolation contract.

Official references:

• https://antigravity.google/docs/cli/settings/
• https://antigravity.google/docs/cli/reference/
• https://antigravity.google/docs/cli-permissions
• https://antigravity.google/docs/cli/commands/permissions

The /permissions TUI also exposes the documented autonomy levels, including request-review, always-proceed, and strict.

Fine-grained permission engine

Google also documents explicit permissions.allow / permissions.ask / permissions.deny rules using action(target) resources, with precedence deny > ask > allow. Examples include scoped command, file, URL and MCP rules.

That provides a future path for a more constrained policy, but it is not necessary to invent one merely to implement the existing issue's explicit guarded vs autonomous UX.

Execution mode is separate from tool permissions

The documented CLI execution mode accept-edits is not equivalent to autonomous tool approval. Google explicitly states that tool permission rules continue to govern shell commands across execution modes. Therefore --mode=accept-edits alone must not be mapped to Remote Dev autonomous.

Reference: https://antigravity.google/docs/cli/modes/

Broad launch flag exists, but should not be the default design

For headless runs Google documents:

--dangerously-skip-permissions

which auto-approves every tool call. The docs explicitly warn that it approves file writes and command execution and recommend scoped permission rules where possible.

Reference: https://antigravity.google/docs/cli/headless/

Because the persistent, documented toolPermission=always-proceed contract exists, this broad bypass flag should remain a fallback/research control rather than the normal Remote Dev autonomous implementation unless real CLI testing proves the persistent setting insufficient.

Recommended Remote Dev mapping to validate

Subject to one real 1.1.22 settings-path/behavior check before implementation:

• guarded: preserve vendor defaults/semantics (toolPermission=request-review, artifactReviewPolicy=asks-for-review) rather than inventing a separate approval engine;
• autonomous: manage only the known reviewed keys needed for the requested behavior, most likely toolPermission=always-proceed plus artifactReviewPolicy=always-proceed;
• keep allowNonWorkspaceAccess=off and the completed security: harden outer containers and add cross-service isolation canaries #42 outer-container mounts/capabilities/read-only-root boundary unchanged;
• do not automatically enable/disable the vendor's inner sandbox merely as a consequence of selecting Remote Dev autonomous mode;
• preserve all unrelated and newer/unknown settings exactly in meaning; malformed/unknown state must fail closed rather than being overwritten wholesale.

One important path question remains before code

The upstream docs locate CLI settings at:

~/.gemini/antigravity-cli/settings.json

Remote Dev currently persists both /root/.gemini/antigravity-cli (vendor state) and a separate /root/.gemini/config mount that was required by the real hardened TrueNAS runtime for its config/projects state. The current repository has no toolPermission/artifactReviewPolicy implementation yet.

Before writing code, perform one sanitized read-only check on the currently installed Antigravity 1.1.22 to determine where these exact documented keys live in the real headless/container setup. Do not print the full settings file or unrelated values; only report the resolved file path and presence/type/value of these documented non-secret permission keys.

Security conclusion

The upstream contract is sufficiently documented to proceed with a focused implementation after that path/behavior confirmation. #159 does not need a new outer security model and must not weaken #42/#153. The desired autonomous behavior can be expressed through official Antigravity permission semantics rather than an undocumented bypass.

No implementation change is made by this research comment.

[eXPerience83]

Blocking dependency discovered from a real data-loss incident: #213.

Do not implement/enable Antigravity autonomous approval behavior before #213 closes. The affected TrueNAS session already demonstrated that a correctly selected child cwd is insufficient when /workspace/.git exists: Git can resolve the collection root and destructive cleanup can delete sibling projects. Removing approval friction before the project-collection boundary and Antigravity non-workspace/sandbox policy are made safe would increase impact.

#213 also requires re-checking the exact final Antigravity upstream contract/version at implementation time, so #159 should consume that proven boundary rather than independently managing overlapping sandbox/settings semantics.

[eXPerience83]

Dependency clarification after the real #213 data-loss incident: upstream permission-contract research for autonomous Antigravity may continue, but implementation/promotion of reduced-confirmation behavior should remain blocked until #213's common /workspace collection/Git boundary is merged and validated on the exact TrueNAS candidate. This does not add a vendor-sandbox dependency: #213 is being narrowed back to the shared Git-boundary fix while preserving the #36/#42 outer-container model.

[eXPerience83]

Dependency clarification after narrowing #213 / PR #214:

#159 should still wait for #213 to close because autonomous Antigravity would increase the impact of any remaining same-role project-boundary defect. However, #213 no longer owns or requires a vendor sandbox/settings policy. Its acceptance gate is now the common project-collection Git boundary, exact project entry/identity checks, safe cwd recovery, diagnostics, and exact-candidate TrueNAS validation.

The earlier #159 comment that described Antigravity sandbox/non-workspace hardening as part of #213 is therefore superseded on that point. Vendor permission/autonomy settings (toolPermission, artifactReviewPolicy, allowNonWorkspaceAccess, inner sandbox semantics, etc.) remain research/implementation concerns of #159 or separate future hardening, not a prerequisite for the Git-boundary P0 fix.

Do not implement #159 until #213 is closed, but do not expand #213 again to solve #159's permission model.

[eXPerience83]

Documentation follow-up created as #215. Current verified baseline is intentionally narrower than “Antigravity sandbox is broken on TrueNAS”: Remote Dev's current run-antigravity does not force vendor --sandbox and does not manage enableTerminalSandbox; current upstream documents that setting as default-off. The completed TrueNAS evidence validates the hardened outer role container, but we do not currently have recorded evidence that AGY's own sandbox was enabled and failed. #215 will synchronize that distinction across security/architecture/README/status docs. Any future decision to enforce the vendor sandbox remains here under #159 (or a dedicated focused security issue) after #213 closes and must be proven on the exact admitted runtime without weakening #42.

[eXPerience83]

2026-09-09 reconciliation — #213 unblocked; sandbox separated from autonomy

Two stale assumptions are now resolved:

1. P0 data loss: enforce project-collection Git boundary for Codex and Antigravity #213 / PR fix: enforce project-collection Git boundary #214 is completed and closed. The project-collection/Git boundary is now the baseline that feat: add autonomous approval mode for Antigravity #159 must preserve, so autonomous implementation is no longer blocked on that dependency.
2. A controlled TrueNAS test on Antigravity CLI 1.1.27 showed that --sandbox is not usable for terminal execution under the unchanged hardened container. unshare -Ur true failed with Operation not permitted; run-antigravity --sandbox started the UI, but terminal execution requested sandbox bypass, and rejecting that bypass caused even pwd to fail with:

Encountered error in tool execution: fork/exec /root/.local/bin/agy: operation not permitted

This confirms the design split:

• feat: add autonomous approval mode for Antigravity #159 = approval/autonomy UX — stop prompting for normal trusted project operations when autonomous is explicitly selected.
• docs/security: document Antigravity inner-sandbox baseline and ownership #215 = inner-sandbox baseline/documentation — current 1.1.27 nested vendor sandbox is not part of the supported TrueNAS path.

Implementation should therefore validate the first-class permission contract (toolPermission, artifactReviewPolicy, actual settings path/semantics on 1.1.27) while preserving allowNonWorkspaceAccess safety and every #42/#153/#213 boundary. Do not use proceed-in-sandbox as the autonomous design, do not force --sandbox, and do not weaken the outer container. Keep --dangerously-skip-permissions only as a fallback if the documented first-class settings prove insufficient.

The issue body has been updated to reflect this current direction.