"Gemini CLI deleted my files": what the issue thread actually shows

The short answer

The best-known “Gemini CLI deleted my files” report, google-gemini/gemini-cli issue #4586 (21 July 2025), says the agent “lost” every file in a folder while trying to organise it on Windows.¹ Later in the thread, after another user questioned the account, the reporter searched more thoroughly and found the files at the root of the C: drive, apologised for the alarm, and said the bug was still valid from a user-experience point of view but much less severe.¹

So the lesson isn’t “Gemini deletes files.” It’s two others: an agent’s account of what it did can be wrong in either direction, and a file move outside the project folder is a real failure even when nothing is deleted.

What the issue reported

The original report, filed as “Gemini CLI ‘lost’ files during a failed file move operation. [Windows]”:¹

Note the “no sandbox” row. The agent ran commands with the user’s full permissions on the whole drive.

How the thread ended

The thread is worth reading in full, because it changes.¹

1. A commenter linked a longer write-up by the reporter.
2. Another commenter argued the write-up’s explanation was technically impossible: the command it blamed doesn’t behave that way, and the transcript showed the destructive steps failing.
3. The reporter first replied that the files were nowhere on the system.
4. The same day, the reporter wrote that a deeper search found the files in the C: root, apologised, and said the Gemini CLI responses and the follow-up “analysis” by two AI assistants had sent them “down a bad rabbit hole.”
5. Another user confirmed a directory being created at the drive root, but only when the directory name contained a space, and linked an older issue.

The issue was closed on 13 May 2026 with a Stale label.¹

Why the agent’s story was wrong

Two separate failures, both common:

The commands did something other than intended. A later commenter saw a folder created at the drive root when a directory name contained a space, which fits where the files turned up.¹ Quoting and paths with spaces are a classic shell trap, and agents generate shell commands at speed.

The agent’s report didn’t match what happened. The agent said the files were lost. They weren’t. Agents describe their own actions from what they think they did, not from a check of the result. When later AI tools were asked to analyse the transcript, they produced a confident explanation the commenters showed couldn’t be right.

That second failure matters for any agent that changes things. A report of “done,” “lost” or “1 row” is a claim, not a measurement. Our 1-row-versus-301 run shows the same gap in a database.

If an agent says it lost your files

Before believing it, check:

1. Stop the session. Don’t let it “fix” things further.
2. Search the whole disk by name, not just the project folder. On Windows, dir C:\ /s /b | findstr /i "filename"; on macOS or Linux, find / -name 'filename' 2>/dev/null. The reporter’s files were in the drive root.
3. Check the recycle bin or trash, and any cloud sync folder’s history.
4. Read the transcript for the actual commands, not the agent’s summary. Look for paths with spaces, wildcards and relative paths.
5. Restore from version control or backup if the files are truly gone. If the folder was a git repository, git status and git reflog tell you a lot quickly.

Protect the folder next time

Gemini CLI has two built-in protections, both off unless you turn them on:

• Checkpointing saves a snapshot of the project before AI tools modify files, as a commit in a shadow git repository in your home directory, and /restore reverts the project files to it. It’s disabled by default; enable it in settings.json under general, since the command-line flag was removed in version 0.11.0. The docs give file-writing tools as the trigger and don’t say shell commands are covered.²
• Sandboxing confines what the agent’s commands can touch. Turn it on with -s or --sandbox, the GEMINI_SANDBOX environment variable, or "sandbox": true in settings.json. On macOS the default Seatbelt profile confines writes to the project directory while allowing reads and network; containers with Docker or Podman are the cross-platform option.³

The case above would have looked very different with either: a sandbox that confines writes to the project folder would have refused a write to the drive root, and a checkpoint would have made “where did my files go” a one-command question.

Two more general habits:

• Run file-organising tasks in a git repository, committed first. Then every move is visible in git status.
• Add a before-tool hook that asks before moves and deletes outside the project. In Gemini CLI, hooks decide allow or deny, with no ask option.⁴ Our post on hooks in Codex, Gemini CLI, Copilot and Cursor shows where each goes.

One note on the product itself: Gemini CLI’s docs carry a banner saying it was replaced by Antigravity CLI for unpaid-tier and Google One users on 18 June 2026.³ If you’ve moved, check which of these settings carried over.

A checklist

• File-moving tasks run in a committed git repository.
• Checkpointing enabled in settings.json.
• Sandbox on (--sandbox or settings), so writes stay in the project.
• Paths with spaces avoided or quoted in your project layout.
• A before-tool hook denies moves and deletes outside the project.
• Agent reports of damage verified on disk before anyone panics.

For a case where a drive really was cleared, see our incident page. To see what an agent on your machine could do without a prompt, paste its config into the check page or run npx deedglass scan (how the grade works); to try tool-call rules in your browser, open the playground.

Written with AI assistance and checked against our claims register.