Title
Antigravity’s Python rewrite command emptied dozens of source files, and Undo did not restore them
Issue
During a firmware refactoring task, Antigravity executed a Python batch-edit command equivalent to:
open(path, "w").write(transform(open(path, "r").read()))
Because the file was opened in write mode first, it was truncated before being read.
Impact
-
Approximately 54 C source/header files were affected.
-
Many files were reduced to a single newline byte.
-
The Git diff showed roughly 6,000 deleted lines.
-
The reported successful build occurred before the destructive command, so it did not validate the resulting workspace.
-
“Undo changes up to this point” had no visible effect or error message.
-
Recovery required restoring the repository from Git, losing uncommitted work.
Privacy note
Project names, local paths, usernames, hardware details, and proprietary source code have been intentionally omitted.
Expected behavior
-
Read the original file completely before opening it for writing.
-
Prefer temporary-file and atomic-replace operations.
-
Create a recoverable checkpoint before batch edits.
-
Preserve existing encoding, BOM, and line endings.
-
Stop automatically when many source files suddenly become empty or shrink abnormally.
-
Verify that builds occur after the final source modification.
-
Make Undo reliable, or clearly report why restoration failed.
Requested investigation
Please investigate:
-
Why this unsafe read/write command was generated and executed.
-
Why no destructive-change safeguard stopped it.
-
Why the workspace was not automatically rolled back.
-
Why the Undo action produced no result or error.
-
Whether session-level checkpoints and recovery exports can be added.