Gemini CLI nightly tackles lost edits and headless stalls

Gemini CLI’s October 1 nightly release includes a change designed to stop concurrent file operations from overwriting one another’s work. It follows a September 30 nightly build that addressed stalled planning and inconsistent folder trust reporting in headless sessions.

These are public changes in Google’s coding tool, with identifiable release records and pull requests. They matter for developers running parallel agents or unattended jobs, where an apparently successful task can still leave an incorrect file or wait for a person who is not connected.

Coordinating competing file edits

The file operation pull request, merged on September 30, describes a race in which multiple tools read the same file before either finishes updating it. One result can then replace the other, leaving a silent lost update. The change adds a lock for each resolved file path so those operations take turns.

It also changes how completed file contents reach disk. The implementation writes to a temporary sibling file and then renames it into place, while preserving existing permissions and handling certain temporary Windows errors. Git snapshot creation is serialized separately to avoid competing operations colliding with the repository lock.

The scope matters. The pull request describes coordination inside the running process. It does not establish that unrelated programs editing the same file are now coordinated, or that every form of data loss has been eliminated. ByteForward has not independently reproduced the author’s test results.

Planning without an absent user

A separate planning workflow change addresses prompts that told a headless agent to consult a user and wait for agreement. In a session without an interactive interface, those instructions could block progress. The revised prompts direct the agent to form a strategy, draft its plan and continue to implementation.

The pull request retains the consultation workflow for interactive sessions. This distinction is important when evaluating the change. The documented fix concerns how planning instructions adapt to the execution mode. It should not be read as a promise that every tool action can run without permission or that an unattended job is safe under any configuration.

Folder trust must reflect the actual workspace

The folder trust repair targets a different inconsistency. In headless mode, part of the interface could be told that a folder was trusted even while the underlying state considered it untrusted. The fix passes along the resolved value, including an undetermined state, and avoids displaying an interactive trust dialog in a headless run.

For automation owners, that is a reason to test both trusted and untrusted workspaces when evaluating the build. A job completing successfully is only one part of the check. Its understanding of the workspace and the boundaries it applies should also match the intended configuration.

Nightly availability is a separate decision

Google’s release channel guidance recommends stable builds for most users. Nightly builds include the current main branch and can have pending validation or unresolved problems. These fixes are therefore useful developments to test in an isolated project, with backups and review of resulting changes, before deciding whether a nightly build belongs in a production workflow.

Featured image is an original AI generated editorial illustration.