Gemini CLI's checkpoint feature keeps its own shadow Git repository to snapshot and roll back project state. That shadow repo only reads .gitignore — it has no way to see .git/info/exclude or a user's global core.excludesFile. The result: /restore treats files kept out of version control through either of those mechanisms as fair game, and can delete or silently revert them.
What the source says
GitHub issue #29654, opened October 6, 2026 against Gemini CLI 0.62.0, open and unfixed. The reporter excluded a personal notes file, notes.local.md, via .git/info/exclude rather than .gitignore — the standard way to keep something local-only without touching a shared .gitignore that the rest of a team sees. They let Gemini edit a tracked file to create a checkpoint, created the excluded notes file, then ran /restore to roll back to that checkpoint. The notes file was deleted outright, with no prompt and no recovery path.
A second user, mahirhir, independently reproduced the same behavior the same day and reported that it also affects the default global ~/.config/git/ignore and linked worktrees. The project's triage bot labeled the issue effort/small; as of this writing no maintainer has commented or merged a fix.
The mechanism generalizes past the one reproduction: a file that exists before a checkpoint and gets edited afterward isn't deleted — it's silently reverted to its old checkpoint contents, with the same blind spot.
What it doesn't establish
This is a narrow precondition. Most users rely on .gitignore alone, and nothing here suggests files excluded that way are at risk. There's also no indication of scale — this is one reporter's single file plus one independent reproduction, not a pattern of widespread damage. The issue being unfixed and unlabeled by a maintainer says something about triage speed, not about whether a fix is hard or planned.
Why it's still worth logging
.git/info/exclude and a global core.excludesFile are exactly what people reach for when they specifically want something kept out of a repo without it showing up in a .gitignore anyone else can see — local secrets, scratch notes, personal config. That makes the set of files this bug can destroy disproportionately the ones nobody has a second copy of. A checkpoint tool that silently narrows "untracked" to "untracked via one specific mechanism" is a sharp edge worth knowing about before you trust /restore with anything you excluded the other way.
Full incident record: https://www.stupidllm.com/incident/STUPID-2026-0132/
Top comments (0)