Gemini CLI v0.64 fixes the CPU hang on @ inside code and headless folder trust

Originally published at https://aicoding-guide.com.

Gemini CLI v0.64.0 adds no features. All 17 entries under "What's Changed" are fixes, refactors or release chores.

Two of them matter a great deal, though: a hang where piping code containing @ into -p pins the CPU at 100%, and a headless mode that treated untrusted folders as trusted. If the first sounds familiar, that alone is a reason to upgrade.

Key point
What this article covers

• Why input like @scope/pkg hung the CLI, and the workaround that worked
• How headless folder trust diverged from the actual trust decision
• File writes and state persistence becoming atomic

Piping code with @ pinned the CPU at 100%

The fix is PR #29557 (Issue #29434). The symptom: piping code into -p on stdin made the CLI stop before it sent anything to the model. In the reporter's words, "The node process sits at ~100% CPU (state RN) indefinitely."

The trigger is input where an @-prefixed token is immediately followed by a double quote, with more quoted strings after it. In practice that means a scoped npm import.

import { x } from "@scope/pkg";
import { y } from "./local";

The symptoms were:

Aspect	Behaviour
Output	Nothing at all, not even an error
--output-format stream-json	Only the init event appears, then it stops
Signals	SIGINT and SIGTERM are ignored; only SIGKILL stops it
Versions reproduced	The reporter names v0.59.0 and v0.60.0

The reporter attributes the cause to the @-path regex matching across multiple quoted spans, so the result falls back to a glob whose large brace expansion minimatch then processes synchronously. That is the reporter's analysis; the fix itself is described only as stopping the CPU hang and quote swallowing caused by @ inside code.

A workaround if you cannot upgrade yet
The reporter writes that escaping every @ in the piped text avoids the hang. If a CI job pipes source code into gemini -p, add that preprocessing step until you can upgrade.

Headless treated untrusted folders as trusted

This is PR #29528 (Issue #29031). In headless mode (-p), the internal folder trust handling always passed the state through as trusted. The result was a mismatch: the warning said the folder was untrusted while the application-level check said it was trusted.

Folder trust exists to stop a project you have not vetted from loading its own configuration. According to the documentation, an untrusted folder disables all of the following:

1. The project's .gemini/settings.json is not loaded
2. The project's .env files are not loaded
3. Extensions cannot be installed, updated or uninstalled
4. Tool auto-acceptance is disabled, so every tool prompts
5. Automatic memory loading from directories in local settings is disabled
6. MCP servers are not connected
7. Custom .toml commands are not loaded, both project and user ones

So while the mismatch lasted, an untrusted folder's settings, hooks and MCP servers could still take effect in a headless run. If your CI relies on this feature, that is a reason to upgrade.

The docs disagree on the default
The settings table gives security.folderTrust.enabled a default of true. The Trusted Folders page says "The Trusted Folders feature is disabled by default." Both live on main in the same repository (checked 2026-10-21). Open /permissions to see which applies in your own setup.

To turn it on explicitly:

{
  "security": {
    "folderTrust": {
      "enabled": true
    }
  }
}

Decisions are stored in ~/.gemini/trustedFolders.json. Running headless against an untrusted folder exits with FatalUntrustedWorkspaceError, so a CI job that must proceed uses the --skip-trust flag or GEMINI_CLI_TRUST_WORKSPACE=true. For MCP configuration, see Setting up MCP servers in Gemini CLI.

Writes and state persistence became atomic

Three fixes address data corruption:

Fix	What changed
PR #29499	File tool operations are serialised and writes are atomic
PR #29558	State persistence is atomic, with recovery from a backup when the state is corrupt
PR #29568	Conversation recording uses append-only delta patching with bounded history windowing

These cover parallel file operations clobbering each other, and a state file left corrupt when the process dies mid-save. They matter most in long-running sessions.

Windows and interaction fixes

Four more that show up in daily use:

• Windows ConPTY now forwards the IME cursor position (PR #29560), fixing misplaced cursors while composing text in an IME
• Ctrl+C emergency abort now reaches the cancellation handler during active operations (PR #29586)
• @file:line references and a ghost-text wrap hang are fixed (PR #29581)
• Enter and Spacebar reliably confirm selection list options (PR #29502)

Beyond those, updating an extension on Windows now retries directory removal through file-locking errors (PR #29540), scroll position is preserved (PR #29520), and ACP resolves sessions by exact ID (PR #29580). For the previous release, see Gemini CLI v0.63 fixes the diff cannot spawn error.

Summary

• v0.64.0 adds no features; all 17 "What's Changed" entries are fixes, refactors or release chores
• Piping code containing @scope/pkg into -p no longer pins the CPU at 100%, a state only SIGKILL could end
• Headless mode no longer treats an untrusted folder as trusted
• File writes and state persistence are atomic, with backup recovery for corrupt state
• The official docs give security.folderTrust.enabled both a true default and "disabled by default"