A checkpoint/undo feature is supposed to be the safe button. In this case, hitting it wiped out a gigabyte of data the agent had nothing to do with.
What the source says
GitHub issue #1675, filed against github/copilot-cli: a user pressed Escape mid-run and chose to restore to an earlier checkpoint — the CLI's built-in undo, meant to revert only what the agent itself had changed during that session.
Instead, the restore path — SnapshotManager.rollbackToSnapshot() — ran git checkout --force and git reset --hard to undo tracked changes, then followed up with git clean -fd against the repository root. git clean -fd doesn't discriminate by who created a file: it deletes every untracked file and directory in the repo. The checkpoint system's snapshots only record what the agent itself modified, so it had no way to know about, and no way to spare, untracked files that came from anywhere else.
In this case, that swept away roughly 1GB of evaluation output — .jsonl and .xlsx files across several directories under output/ — generated by a separate Python script the agent had only read from during the session, never created or modified. There was no trash or recovery step; git clean -fd removes files outright.
The reporter proposed four fixes: track and remove only files the agent actually created instead of a blanket clean; skip git clean entirely since the snapshot mechanism already restores individual files on its own; warn with a file count and size estimate before deleting anything; or move swept files to a recoverable trash location instead of deleting them. The issue was closed with no maintainer explanation recorded on the thread.
What it doesn't establish
The issue is closed without comment, so there's no confirmation of whether — or how — this was fixed. It's one reporter's account, not an independently reproduced multi-user pattern, though the mechanism (a rollback routine that shells out to git clean -fd) is verifiable from the described behavior and is exactly the kind of bug that reproduces reliably given the same setup: untracked files outside the agent's own working set, sitting in the repo when a checkpoint restore fires.
Why it's worth knowing
The interesting part isn't "an agent deleted files" — it's that the safety feature did it. Checkpoint/rollback systems are supposed to be the thing you reach for when an agent run goes sideways. This one's blast radius extended past what it was designed to protect: it could only ever track the agent's own edits, but it cleaned the whole repo root, so anything else living untracked in that directory — build output, generated data, a script's results — was exposed with no way for the snapshot system to know better. If you're using or building an undo/checkpoint feature that shells out to git clean, this is the scope failure to check for before you rely on it.
Top comments (0)