Gemini CLI 0.64.0 Release Notes List Fixes for Headless Folder-Trust Reporting, Atomic File-Tool Writes and State-File Recovery

Overview

Gemini CLI, a terminal coding agent developed in the google-gemini GitHub organization, has a new release. The v0.64.0 release page on GitHub was published on October 13, 2026 (20:44 UTC). Its “What’s Changed” list is made up largely of fixes. Three of them concern how the agent reports workspace trust, writes files and stores its own state, and each has a pull request whose description explains the change. The descriptions are written by the contributors who submitted the changes, so the explanations below are the contributors’ account rather than an independent test of the release.

What the release lists

The release notes include an entry titled “fix(cli): propagate resolved folder trust state in headless mode (#29031)”, an entry titled “fix(core): serialize file tool operations and make writes atomic (#29078)”, and an entry titled “fix(cli): persist state atomically and recover from backup on corruption”, according to the v0.64.0 release notes. The notes carry no prose summary beyond the list of changes and a link to the full changelog.

Headless folder trust

The pull request description for the folder-trust fix says the problem was in the useFolderTrust hook. In headless mode it always told the parent component that the folder was trusted, even when the workspace was untrusted. The description calls the result a “split-brain state”: the hook’s internal state and history log warned of an untrusted folder while the parent component and its consumers were told the folder was trusted. Per the description, the change makes the hook pass along the actual resolved value (true, false or undefined) and stops the interactive trust dialog from opening in headless mode. The description does not say what, if anything, the parent component did differently when it was told the folder was trusted, so the practical effect of the mismatch is not described there.

Serialized and atomic file writes

According to the description of the file-tool change, the fix targets race conditions when several tool invocations, notably parallel sub-agents, act on the same file at once. It says that uncoordinated read-modify-write sequences caused silent lost updates, inaccurate diff calculations and collisions on the shadow Git snapshot’s .git/index.lock. The description lists these remedies:

• an in-process, per-path async mutex called withPathLock;
• serialized read-modify-write sections in the edit and write-file tools;
• atomic writes in StandardFileSystemService.writeTextFile through a temporary sibling file that is then renamed, with retries on Windows EBUSY, EPERM and EACCES errors;
• serialized shadow-repository snapshot creation per project root.

In its manual verification section the contributor reports that a concurrent reader saw no partial or truncated reads during a 10MB write, and that two sub-agents appending to the same file kept both lines. These are the contributor’s own results as written in the description. The mutex is described as in-process, so the description does not claim to coordinate writes made by separate processes.

State-file recovery

The description of the state-persistence change concerns ~/.gemini/state.json. It says state is now written to a temporary file, flushed with fsync and renamed into place; the previous state is rotated to state.json.bak; a file that fails to parse is preserved as state.json.corrupt; and loading falls back to the backup when the main file is corrupt. The description names an interrupted write or crash as an example of how a file can fail to parse.

What the sources do not show

The release notes do not say whether any user reported data loss or an incorrect trust decision from these issues, and the pull request descriptions give no figures on how often they occurred. The release page lists other entries, including fixes to Windows ConPTY input handling and ACP session handling, that this article does not examine. The checklist in each description marks different platforms as validated: the file-tool description ticks Linux with npm run, the state description ticks Linux with npm run, and the folder-trust description ticks macOS with npm run. None of the three marks Windows as validated, although the file-tool change includes Windows-specific retry logic.