Gemini CLI v0.64 fixes the CPU hang on @ inside code and headless folder trust
v0.64.0 ships no new features. It fixes a hang where piping @scope/pkg into -p pinned the CPU at 100%, and a headless mode that treated untrusted folders as trusted.
Contents
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/pkghung 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:
- The project's
.gemini/settings.jsonis not loaded - The project's
.envfiles are not loaded - Extensions cannot be installed, updated or uninstalled
- Tool auto-acceptance is disabled, so every tool prompts
- Automatic memory loading from directories in local settings is disabled
- MCP servers are not connected
- Custom
.tomlcommands 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:linereferences 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/pkginto-pno 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.enabledboth atruedefault and "disabled by default"
FAQ
- Does v0.64.0 add any features?
- No. All 17 entries under What's Changed are fixes, refactors or release chores.
- Which versions hang when you pipe code containing @?
- The reporter reproduced it on v0.59.0 and v0.60.0. The fix landed in PR #29557 and ships in v0.64.0.
- Is folder trust on by default?
- The official docs contradict each other. The settings table gives security.folderTrust.enabled a default of true, while the Trusted Folders page says the feature is disabled by default (checked 2026-10-21).
Primary sources
This article was drafted by AI from official documentation and reviewed by the site operator before publishing. Found a mistake? Let us know via the contact page.