What happened with Gemini CLI in STUPID-2026-0132?

Gemini CLI's checkpoint system snapshots and restores state through an isolated shadow Git repository. That shadow repo reads the project's `.gitignore` but has no visibility into `.git/info/exclude` or the user's global `core.excludesFile`, so it treats files excluded only through those mechanisms as part of the trackable state. A file created after the checkpoint and excluded this way was deleted outright by `/restore`; a file that existed before the checkpoint and was edited afterward was silently reverted to its old checkpoint contents.

How severe was the Gemini CLI failure?

The incident was rated 5.6/10 (medium). In the reporter's reproduction, a personal notes file (`notes.local.md`) excluded via `.git/info/exclude` was deleted by `/restore` with no prompt and no recovery path. A second user (mahirhir) independently reproduced the same behavior the same day, and found it also affects the default global `~/.config/git/ignore` and linked worktrees. The bug generalizes to any file kept out of version control other than through `.gitignore` — local secrets, scratch files, or notes — created or edited between checkpoints. As of this writing the issue is open and unfixed; the project's triage bot labeled it `effort/small` but no maintainer has commented or merged a fix.

What caused the Gemini CLI failure?

The root cause was classified as Logic Error. The instruction given was: No specific task — this surfaces during ordinary use of Gemini CLI's built-in checkpointing. The reporter excluded a personal notes file via `.git/info/exclude` (not `.gitignore`), let Gemini edit a tracked file to create a checkpoint, created the excluded file, and then ran `/restore` to roll back to that checkpoint.

STUPID-2026-0132

Gemini CLI's /restore deleted and reverted files excluded via .git/info/exclude, not just .gitignore

5.6

medium

October 6, 2026VerifiedReproducible

Instruction given
No specific task — this surfaces during ordinary use of Gemini CLI's built-in checkpointing. The reporter excluded a personal notes file via `.git/info/exclude` (not `.gitignore`), let Gemini edit a tracked file to create a checkpoint, created the excluded file, and then ran `/restore` to roll back to that checkpoint.
Expected behavior
Files excluded from Git tracking via `.git/info/exclude` or the user's global `core.excludesFile` should be left untouched by `/restore`, exactly like files ignored through the project's `.gitignore`.
Actual behavior
Gemini CLI's checkpoint system snapshots and restores state through an isolated shadow Git repository. That shadow repo reads the project's `.gitignore` but has no visibility into `.git/info/exclude` or the user's global `core.excludesFile`, so it treats files excluded only through those mechanisms as part of the trackable state. A file created after the checkpoint and excluded this way was deleted outright by `/restore`; a file that existed before the checkpoint and was edited afterward was silently reverted to its old checkpoint contents.
Damage
In the reporter's reproduction, a personal notes file (`notes.local.md`) excluded via `.git/info/exclude` was deleted by `/restore` with no prompt and no recovery path. A second user (mahirhir) independently reproduced the same behavior the same day, and found it also affects the default global `~/.config/git/ignore` and linked worktrees. The bug generalizes to any file kept out of version control other than through `.gitignore` — local secrets, scratch files, or notes — created or edited between checkpoints. As of this writing the issue is open and unfixed; the project's triage bot labeled it `effort/small` but no maintainer has commented or merged a fix.

A Gemini CLI user excluded a personal notes file from version control the normal way for secrets and scratch content — through `.git/info/exclude` rather than `.gitignore` — then used the CLI's checkpoint feature while editing a tracked file. Running `/restore` to roll back to that checkpoint deleted the excluded file outright. The cause: Gemini CLI's checkpoint system keeps its own shadow Git repository to snapshot and restore project state, and that shadow repo only consults the project's `.gitignore` — it has no way to see `.git/info/exclude` or a user's global `core.excludesFile`, so it treats anything excluded only through those mechanisms as fair game. A file created after the checkpoint is deleted; one that existed before and was later edited is silently reverted to its old contents. A second developer reproduced the bug independently the same day and found it also breaks the default global ignore file and linked worktrees. It is a narrow precondition — most users rely on `.gitignore` alone — but exactly the kind of precondition people reach for when they specifically want something kept out of a repo without being tracked anywhere, which makes the files it destroys disproportionately the ones nobody has a second copy of.

Classification

Agent: Gemini CLI
Failure mode: Destructive Action
Root cause: Logic Error
Domain: Infra
Source: Github Issue

Related incidents

10.0

Gemini CLI silently executed arbitrary code from an untrusted repo (CVE-2026-12537, CVSS 10.0)

10.0

GPT-5.6-Sol 'accidentally deleted almost ALL' of a tester's Mac files during OpenAI's Ultra mode trial

10.0

Cursor AI agent deleted PocketOS's entire production database and backups in 9 seconds

10.0

Replit AI agent wiped SaaStr's production database during a code freeze, then hid the rollback

Discuss on Hacker News

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.

Instruction given

Expected behavior

Actual behavior

Damage

Classification

Related incidents