The laptop is closed, but the agent is still working. That is the appealing part of Google's Antigravity update. The less obvious question is which files it is working on, and which permission rules followed it into the cloud.

Friday's coverage from 9to5Google describes Remote Agents alongside a redesigned app and Gemini Live-powered voice mode. Google's own changelog dates version 2.29.0 to November 3 and says the rollout is gradual. This is an expanding rollout, not evidence that every eligible account received the same feature today.

Remote is a location, not a promise about your checkout

Google's Remote Agents guide separates two products that are easy to confuse. Remote Agents execute in an isolated, Google-managed environment and keep working when the viewing computer sleeps. Remote Control connects to your own workstation or server, which must remain powered on and online.

That difference decides whether closing a laptop is harmless. If the laptop is the executing host, a phone view does not move the work elsewhere. If execution is already in Google's remote environment, the local machine does not have to stay awake.

It also decides what the agent can see. A remote project uses attached GitHub repositories, Google Drive resources and uploaded files. Starting the remote CLI inside a local directory does not give it that directory's files. Google says it cannot read or change files on your machine.

The warning can leave a conversation running

One documented CLI behavior deserves more attention than the redesign: if the project name or ID supplied with --project does not exist, the CLI warns and uses the machine's default remote project instead. It does not simply refuse to start.

That creates a practical check before the first prompt. Confirm the selected remote project, the repository and the specific material attached to it. A running conversation proves that something started. It does not prove that the intended project opened. This is a risk inferred from the documented fallback, not an incident we observed.

Moving an existing task is not a transparent continuation, either. Remote sessions open remote conversations; local sessions open local ones. Google's guide also lists local MCP servers, plugins and agent skills among the features unavailable in remote CLI sessions. Remote service plugins can be connected separately, but that is different from inheriting a laptop's setup.

Read the permissions again

Remote permissions are separate from local rules. The guide says the remote preset defaults to always-proceed (turbo) unless changed, meaning commands run without asking for approval. It also documents a default preset that asks before sensitive operations and a request-review preset that asks before every command.

Our recommendation is to inspect those remote rules before attaching valuable resources or giving a task with external effects. Check the selected project and permissions together. Fixing the workspace after a permissive conversation has begun is the wrong order.

Availability is narrower than the phrase "Google subscribers" suggests. Google lists personal accounts with Google AI Pro or Ultra and excludes the free plan, AI Plus and business accounts. Rollout remains gradual. A company evaluating this for employees should not assume a Workspace account qualifies.

The useful advance is work that can continue away from a desk. The useful habit is verifying what moved with it. Before celebrating a result from a sleeping laptop, check the project, the inputs, the permissions and the actual output. Cloud execution changes where the work happens. It does not establish that the right work finished.

Reporting note: documentation-led analysis, not a hands-on review. We did not install Antigravity, run a remote session or test its controls. ByteForward and OpenTools also discuss the rollout and its limits; neither substitutes for an independently reproduced result.