Antigravity 09-2026: file edits, hook coverage, and stale-state rejection

A version change can move the authorization boundary

Google's September 17 release note replaces the May preview with antigravity-preview-09-2026. Remote runs that consume only text need the new agent identity; local tool dispatch or parsed function calls also need attention. File parameters now use PascalCase, and editing moves from whole-file writes to range replacements. The relevant new edit tool is replace_file_content, with TargetFile, StartLine, EndLine, TargetContent, and ReplacementContent.

This creates an application question: which observed file state authorizes that exact change? A syntactically accepted tool call can still target an obsolete range after a human inserts a line. This note develops an original, unexecuted fixture for one disposable file. It neither changes Kumyu's tool runner nor invokes a paid agent.

The deprecation table lists October 5, 2026 for the May preview and cautions that listed dates are the earliest possible retirement dates. At this October 4 observation, that is an announced boundary, not proof that shutdown has happened. Do not keep an old request dispatcher as a silent recovery branch.

From screen actions to a concrete file contract

Anthropic's October 2024 computer-use announcement made screen observation and actions a public agent interface. Google's May 19, 2026 release-note section introduced its managed Antigravity preview; the September section changes its file contract. These are distinct provider events, not a claim that one product descends from the other. The persistent engineering problem is that a proposed action must remain tied to the environment it observed.

The current Antigravity guide describes a Google-hosted Linux environment and supports restricting tools. A hosted execution environment and a local dispatcher have different owners. Record which one is involved before applying advice about hooks. This note does not establish the local dispatcher API or the provider's line-index conventions from an abbreviated release table.

1. 1One permitted file and current digest
2. 2Observe the intended range
3. 3Propose one replacement

1. 1Tool identity plus path plus state check
2. 2Authorize the exact edit
3. 3Verify the resulting file

1. 1Unknown tool, changed digest, or mismatched target
2. 2Reject before mutation
3. 3Record the reason

A hook that exists may not cover the action

The official hook documentation matches container tool names using RE2 patterns. Its suffix example does not include replace_file_content; a rule covering names ending in _file leaves that edit operation uncovered. Audit coverage against actual tool identities, including shell execution as a separate path to modifying files.

The same document says that a crash, HTTP error, timeout, or unrecognized decision JSON is treated as approval. An explicit denial cancels the call; an unavailable hook does not establish denial. Consequently, a remote pre-tool hook alone cannot meet a requirement that authorization failures stop mutation. This is documented provider behavior, not a penetration-test result.

For a local implementation, the original policy proposed here is direct: evaluate permission inside the sole mutation path and proceed only after an explicit successful result. Unknown names, invalid arguments, unavailable policy, and failed state comparisons terminate that request. For a hosted design whose only veto is the documented hook, leave sensitive writes disabled until a separate enforced boundary has been established. Changing a prompt or adding more hook patterns does not change the runtime's failure semantics.

Rehearse one edit with disposable state

Use an offline worksheet before implementing an integration. Number the worksheet's lines from one for readability; verify the actual provider's range and newline semantics separately before sending a real call. Create a three-line fixture containing name=demo, mode=draft, and owner=fixture. The only permitted change is the middle line to mode=reviewed. These strings are original exercise data.

Case	Condition	Required worksheet outcome
Authorized edit	Current file digest, exact target text, allowed file and new tool identity	One replacement; the first and third lines are unchanged.
Concurrent insertion	A line is inserted after observation	Reject the stale digest before writing.
Wrong text	The range no longer contains the recorded target	Reject; do not search for another occurrence.
Escaping path	The proposed path resolves outside the fixture, including a symbolic link	Reject before opening a writable handle.
Policy failure	The checker times out or gives no valid decision	Reject and leave bytes unchanged.
Obsolete request	Old tool name or old parameter casing	Reject the unsupported contract.

A local implementation must make state comparison and mutation one serialized operation for that file. Checking a digest, releasing the file, and later writing introduces a race. Keep the target unavailable to concurrent writers for this small rehearsal; do not create a reusable editing framework before another actual consumer needs it. Verify all final bytes, not just a success message. A correct diff can still fail a project build, so define a separate semantic check appropriate to the file.

Diagnose the first failed boundary

Record tool identity, normalized path, input digest, decision, expected diff, final digest, elapsed time, and stop reason. Use only the disposable file; logging a production file or a full function payload can expose secrets. A schema rejection indicates a contract problem, a digest mismatch indicates stale observation, and unexpected final bytes indicate a mutation or concurrency problem. Keep these separate from model task quality.

Set one request deadline and small file-size limit. Offline work consumes time and local resources; a later hosted rehearsal may incur model, sandbox, network, and storage costs. Check current account terms before it is separately authorized. No agent request, remote file write, hook-failure injection, or performance/security benchmark was executed for this article. The proposed outcomes are acceptance criteria, not measurements.

Community reports need the right product identity

The readable September 23 Reddit thread discusses desktop v2.16.0, WSL and reopening conversations. Comments describe Linux model availability and an IDE-extension edit replay problem. Exact builds, payloads and reproductions are absent. These are community reports about particular surfaces; they do not verify Gemini API file tools or hosted hooks. Their useful lesson is to record product surface and version before diagnosing an apparent regression.

Continue with the computer-use evaluation worksheet. This new note adds file-contract and authorization failure cases to its observed-state discipline. It does not claim a successful migration or an automatically safe agent.