Antigravity Remote Control for QA can help an engineer monitor a long regression investigation from another browser or mobile device while the agent continues on its host machine. That convenience creates a new test surface: the reviewer must know which machine, conversation, repository, and agent run they are controlling, especially after a disconnect or notification.
Google’s official documentation says Remote Control can expose active conversations, new-task creation, implementation plans, and artifacts through a web dashboard. It also says the dashboard uses the same Google Account as the host application and an instance switcher to choose a machine. This tutorial turns those behaviors into a repeatable QA protocol without granting production access or weakening the host’s permission policy.
Why remote agent monitoring needs its own QA plan
A long-running agent can outlive the laptop session, browser tab, or network path used to launch it. A remote dashboard may reconnect while host-side work continues. If the reviewer acts on stale status, selects the wrong instance, approves a duplicated command, or trusts an old artifact, the remote convenience can hide a serious control failure.
Test five boundaries separately:
- Identity: the correct account, host, instance, repository, conversation, and task;
- Continuity: what continues when the remote UI disconnects;
- Authority: which actions still require host-side permission or review;
- Evidence: whether plans, logs, artifacts, and Git state are fresh and complete; and
- Recovery: how the team reconnects, intervenes, stops work, and disables the service.
Build a disposable long-running test fixture
Use a dedicated QA workstation or virtual machine with a private test repository. Create a regression investigation that lasts long enough to exercise reconnection and notification paths, but keep the workload deterministic.
A useful fixture contains:
- one seeded API contract defect with a known root cause;
- a focused reproduction suite and a full regression suite;
- a controlled slow phase such as a bounded matrix of browser or integration tests;
- immutable run reports with timestamps and hashes;
- a clean control branch where no code change is required;
- synthetic secret canaries in logs and fixtures;
- a fake approval-required action that must never auto-run; and
- an emergency-stop marker the reviewer can verify independently.
Do not use live customer data, production credentials, merge rights, deployment access, or broad cloud permissions. Remote Control should be evaluated on the same least-privilege configuration intended for daily QA.
Freeze every identity before the run
Record the Antigravity surface and build, host operating system, desktop versus headless-daemon path, host nickname, instance name, Google Account tenant, repository URL, branch, base and head commit, working directory, conversation and task IDs, agent and model configuration, permission-file hash, sandbox settings, allowed URLs, network route, notification state, time and cost budgets, expected artifacts, and expected side effects.
Use distinct, descriptive instance names. Google’s Remote Control documentation notes that editor and headless-daemon entries on the same machine are separate by design. Similar default names are therefore a real mis-selection risk, not cosmetic noise.
run_id: rc-qa-20260909-01
host_name: qa-lab-windows-01
instance_type: desktop
instance_name: qa-lab-desktop
repo_head: <commit SHA>
conversation_id: <ID>
task_id: <ID>
permission_hash: <hash>
sandbox_state: enabled
expected_side_effects: workspace-only
release_authority: human-onlyPair the dashboard and prove account scope
Enable Remote Control on the dedicated host, open the dashboard from a second browser, sign in with the same test account, and select the named instance. Capture the host settings, dashboard account, instance switcher, and active conversation in one evidence set.
Run negative account tests with a different test account, a signed-out browser, an expired session, and a browser profile containing another tenant. Expected behavior should be explicit: the wrong account must not reveal the host instance or its artifacts. Never use a real employee’s personal account as the negative fixture.
Test correct and incorrect instance selection
Create two safe instances with deliberately similar workloads but clearly different names, repository SHAs, and synthetic canaries. Select each from the dashboard and verify all visible identifiers before sending a prompt or reviewing a plan.
Exercise:
- desktop and daemon entries on the same host;
- two machines with similar generated names;
- a renamed instance before and after service restart;
- an offline host still visible in cached UI;
- a stale browser tab opened before the rename;
- a host that is asleep or suspended; and
- a conversation with the same title on two instances.
Require the remote reviewer to echo the instance name, task ID, repository SHA, and last evidence timestamp before any consequential instruction. Reject the action if one value is missing or stale.
Validate reconnect behavior
Google documents that when the remote web interface temporarily loses network connectivity, it attempts to reconnect while background agent tasks and shell commands continue on the host if that host remains connected. This makes reconnect testing essential.
Start the bounded long-running suite, then disconnect only the remote client. Record host-side process state, command ID, start time, and report directory. Reconnect and confirm that the dashboard attaches to the same task instead of creating a duplicate. Next, disconnect the host network and verify how the dashboard distinguishes “client disconnected,” “host unavailable,” and “task completed while status was stale.”
Also test browser refresh, tab closure, mobile backgrounding, device sleep, account reauthentication, and rapid reconnect loops. After every recovery, compare dashboard state with host process lists, test reports, Git status, and the task ID. Do not infer continuity from a progress animation.
Prevent duplicate remote actions
A delayed UI can tempt a reviewer to press a control twice or resend a prompt. Give each remote instruction a unique command ID and expected state transition. Send one command, refresh during the acknowledgment window, and verify exactly one host-side execution.
| Scenario | Expected evidence |
|---|---|
| Single action | One command ID and one result |
| Double click | Second request rejected or safely deduplicated |
| Refresh after send | Existing action rediscovered, not repeated |
| Two remote devices | Clear ordering and no conflicting execution |
| Stale approval card | Expired or rebound to current task identity |
If the product does not expose idempotency directly, create a safe test harness that logs the unique ID at the host boundary and refuses duplicates. The test must observe real host execution, not only UI messages.
Keep permissions on the host
Remote Control changes where the user observes and steers the session; it should not silently change what the agent may do. Google’s Agent Permissions documentation defines Deny, Ask, and Allow lists, with Deny taking precedence. It separately covers terminal commands, files, URL reads, browser actuation, MCP tools, and unsandboxed execution.
Test denied file access, a command requiring review, an unapproved URL, browser interaction on an untrusted domain, an MCP mutation, and a sandbox-bypass request. Verify that remote prompts cannot weaken the permission file or convert a one-time approval into a broad permanent grant without clear review.
The official settings guide also documents workspace boundaries, strict review policies, and sandbox controls. Keep those settings frozen for the entire experiment and hash them again afterward.
Test plans and artifacts for freshness
Remote users can review implementation plans and inspect artifacts. Seed one stale passing report from another commit and one fresh failing report from the active task. The dashboard should make it possible for the reviewer to connect each artifact to the current host, conversation, task, repository SHA, and timestamp.
Require every evidence artifact to include:
- run, task, and command IDs;
- host and instance names;
- repository SHA and dataset hash;
- command, exit code, and suite counts;
- report timestamp and content hash;
- approval decision and reviewer identity; and
- a side-effect scan covering Git, files, network, and external systems.
Open the report independently on the host after reconnect. A remote screenshot can support review, but it does not replace the underlying artifact.
Verify mobile notifications without notification-driven approval
Google says mobile users can optionally install the dashboard web app and receive push notifications when agents finish or request input. Test notification delivery, delay, deduplication, ordering, deep-link destination, account scope, cleared notifications, and notification behavior after the task is canceled or the instance is renamed.
Notifications should bring the reviewer to fresh context. They should not themselves approve a command, merge a change, or prove that a task succeeded. After opening one, revalidate the instance, task ID, repository SHA, and current permission request before acting.
Exercise daemon lifecycle and shutdown
For a headless fixture, test service start, status, naming, restart, crash recovery, stop, and re-registration. Google’s documentation says startup behavior varies by operating system and that Windows start-at-boot requires administrator installation; without it, the daemon resumes after login rather than at boot.
Include tests for missing sign-in, expired credentials, a restart after renaming, two similar Hub entries, an older competing service, and a host reboot. At the end of the experiment, stop and unregister the unused daemon, disable Remote Control on the test host, and verify the instance disappears from the dashboard.
Measure the control, not just uptime
Track machine-selection accuracy, task-identity integrity, duplicate command rate, reconnect recovery time, notification precision and latency, approval correctness, permission-boundary violations, evidence freshness, artifact completeness, test continuity, secret-canary leakage, unexpected side effects, and mean time to safe intervention.
A successful remote session is not merely one that reconnects. It must reconnect to the correct work, show fresh evidence, preserve host restrictions, avoid duplicate actions, and let a human stop the run safely.
Final QA checklist
- The account, host, instance, conversation, task, and repository identities match.
- Desktop and daemon entries have distinct names.
- Client and host disconnections were tested separately.
- Reconnect did not duplicate a command or task.
- Two-controller conflicts were exercised.
- Notifications deep-link to the correct current task.
- Deny, Ask, Allow, sandbox, and workspace controls remain host-enforced.
- Plans and artifacts include fresh task and repository identifiers.
- No synthetic secret canary appears in the dashboard, screenshot, notification, or log.
- Git status, test reports, processes, and external systems were verified independently.
- Emergency stop and daemon removal were proven.
- Production access, merge, deployment, and release remain human-controlled.
Conclusion
Antigravity Remote Control for QA is most valuable when it extends observability without obscuring authority. Use a dedicated least-privilege host, assign distinct machine identities, freeze permission and repository state, test disconnects and duplicates, and reconnect to evidence rather than assumptions. The remote dashboard can help a reviewer stay involved in a long-running investigation, but the host’s controls and independent QA evidence must remain the source of truth.