[FEATURE] maintain a recoverable edit history / snapshot of all file changes for 24 hours

Resolved 💬 5 comments Opened Mar 20, 2026 by jbrouhard98 Closed Apr 17, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Problem

Claude Code can irreversibly destroy a user's working code with no way to recover it.

I asked Claude Code to package my working C application as an AppImage — a packaging-only task that required adding one line to a build script. Instead, Claude:

  1. Diagnosed a non-existent bug — saw zeros in audio capture logs and assumed the capture code was broken, without verifying the actual cause (a bundled library incompatibility in the AppImage)
  2. Rewrote working code it was never asked to touch — modified audio capture, signal processing thresholds, gain normalization, hallucination filters, and swapped the entire audio backend
  3. Used the Write tool to overwrite files — completely replacing file contents, destroying the original working code in the user's git working tree (uncommitted changes from a multi-file migration)
  4. Could not recover — when the changes broke everything, there was no way to get back to the original state. The files were not committed to git (they were in-progress working tree changes), and Claude Code has no edit history or rollback mechanism

The result: hours of debugging problems that didn't exist before Claude touched the code, and permanent loss of working code that cannot be reconstructed.

Root Cause

Claude Code has no safety net for file modifications. When it uses Write or Edit to modify files, the previous content is gone. There is no undo, no snapshot, no history. A single bad Write call can destroy hours or days of work.

Proposed Solution

Proposed Solution

Claude Code should maintain a recoverable edit history:

  • Snapshot every file before modifying it — before any Write or Edit tool call, save the original file content to a local history directory (e.g., ~/.claude/history/)
  • Retain snapshots for at least 24 hours — so users can recover from bad edits even across sessions
  • Provide a recovery command — e.g., /undo or /history <file> to list and restore previous versions
  • Warn before overwriting uncommitted changes — if a file has uncommitted git modifications, require explicit confirmation before overwriting with Write

Impact

Without this, users must treat Claude Code as capable of permanently destroying their work at any time, with no recourse. This is especially dangerous for:

  • Uncommitted working tree changes (not protected by git)
  • Multi-file migrations or refactors in progress
  • Users who trust Claude to only modify what was requested

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

I asked Claude Code to package my working C application as an AppImage — a packaging-only task that required adding one line to a build script. Instead, Claude:

  1. Diagnosed a non-existent bug — saw zeros in audio capture logs and assumed the capture code was broken, without verifying the actual cause (a bundled library incompatibility in the AppImage)
  2. Rewrote working code it was never asked to touch — modified audio capture, signal processing thresholds, gain normalization, hallucination filters, and swapped the entire audio backend
  3. Used the Write tool to overwrite files — completely replacing file contents, destroying the original working code in the user's git working tree (uncommitted changes from a multi-file migration)
  4. Could not recover — when the changes broke everything, there was no way to get back to the original state. The files were not committed to git (they were in-progress working tree changes), and Claude Code has no edit history or rollback mechanism

The result: hours of debugging problems that didn't exist before Claude touched the code, and permanent loss of working code that cannot be reconstructed.

Additional Context

Yes a fully updated git with last known good working would have saved me here, but I never asked claude to modify any files, just repackage in AppImage. instead it just randomly went ahead and made massive amount of changes that completely broke the app i'm working on . This is a Livecaption tool for the deaf, and being deaf myself, this breakage creates a massive problem.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗