›_ Claude Code Issues
Claude Code Issues / #17190

Bug: Claude Code uses destructive 'git reset --hard' instead of safe 'git checkout' for rollback requests

Resolved 💬 3 comments Opened Jan 9, 2026 by AddisonJeff Closed Jan 13, 2026

Anthropic Bug Report: Claude Code Destructive Git Behavior

Report Date: January 9, 2026
Reporter: Jeff Kelling
Project: Care Connect API
Claude Version: Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
Claude Code Version: 2.0.65

---

Summary

Claude Code chose a destructive git command (git reset --hard) when a non-destructive alternative (git checkout) would have been appropriate, resulting in permanent loss of several hours of uncommitted work.

---

What Happened

User Request

User said: "I want to save where we are and ROLL BACK to the last push"

Context: User wanted to temporarily view old code for a demo, with intention to return to current work afterward.

Claude's Actions

  1. git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" ✅ (Correct)
  2. git reset --hard 35eb731 ❌ (DESTRUCTIVE - Wrong choice)

What Should Have Happened

  1. git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" ✅
  2. git checkout 35eb731 ✅ (Non-destructive, reversible)
  • OR: git checkout -b demo-branch 35eb731 (Even safer)

Result

  • User was at commit 882e618 (HEAD) with uncommitted changes
  • Reset moved HEAD back 5 commits to 35eb731
  • Commits d63695e through 882e618 became orphaned
  • When user later tried to restore, Claude moved to 882e618 but the uncommitted work from that morning was permanently lost
  • User lost several hours of billable work (leaveRemove method, middleware refactoring, etc.)

---

Root Cause Analysis

Why This is a Bug

  1. Ambiguous Language Interpretation:
  • User said "ROLL BACK" (commonly means "go back and look")
  • Claude interpreted as "destroy and rewrite history"
  • In professional development, "rollback" typically means non-destructive viewing
  1. Wrong Command Selection:
  • git reset --hard is for REWRITING history (rare, dangerous)
  • git checkout is for VIEWING history (common, safe)
  • Claude should default to the safer option
  1. No Confirmation Request:
  • Claude did not ask: "This will permanently destroy uncommitted work. Confirm?"
  • Claude did not explain the difference between reset and checkout
  • User assumed "stash" would save everything (reasonable assumption)
  1. Contradictory to Project Instructions:
  • User's CLAUDE.md explicitly says: "⚠️ DON'T EVER RESTORE FROM GITHUB WITHOUT ASKING FIRST"
  • git reset --hard is a form of destructive restoration
  • Claude violated this rule without asking

---

Expected Behavior

Claude Should:

  1. Default to Non-Destructive Commands:
  • Use git checkout for "go back", "rollback", "restore", "look at old code"
  • Only use git reset --hard when user explicitly says those exact words
  1. Always Confirm Destructive Operations:

```
User: "Roll back to the last push"

Claude: "I can do this two ways:

  1. SAFE (Recommended): Use 'git checkout' to temporarily view the old code.

You can easily return to your current work afterward.

  1. DESTRUCTIVE: Use 'git reset --hard' to permanently destroy uncommitted

changes and rewrite history. This cannot be undone.

Which would you like?"
```

  1. Respect Project-Specific Rules:
  • CLAUDE.md said "don't restore without asking"
  • Claude should have asked before any git operation that changes HEAD
  1. Educate Users About Git Commands:
  • Explain the difference between checkout (safe) and reset (destructive)
  • Help users understand the implications before executing

---

Impact

Immediate Impact

  • ~4 hours of work lost (estimated)
  • User cannot bill customer twice for same work
  • Loss of leaveRemove method implementation
  • Loss of middleware refactoring/renaming
  • Loss of other tracker improvements

Trust Impact

  • User now questions trusting git at all
  • User considering reverting to "multiple folder copies" approach (less professional but safer)
  • Erosion of confidence in Claude Code's git handling

Business Impact

  • Developer time wasted redoing work
  • Unbillable hours spent on recovery attempts
  • Potential delay in project delivery

---

Reproduction Steps

  1. Have a git repository with:
  • Recent commits (e.g., commit A, B, C, D, E)
  • Uncommitted changes in working directory
  • Currently at HEAD (commit E)
  1. Ask Claude: "Save my work and roll back to commit A for a demo"
  1. Observe: Claude uses git reset --hard A instead of git checkout A
  1. Result: Commits B-E become orphaned, uncommitted work is destroyed

---

Suggested Fixes

1. Update Git Command Prioritization

User Intent: "go back", "rollback", "restore", "look at old code"
Default Command: git checkout <commit>
Alternative: git checkout -b temp-branch <commit>
NEVER: git reset --hard (unless user explicitly says it)

2. Add Confirmation Layer

Before ANY destructive git operation:

  • Explain what will happen
  • List what will be lost
  • Offer safer alternative
  • Require explicit confirmation

3. Enhance Project Rules Awareness

When project has CLAUDE.md with warnings about git operations:

  • Treat ALL git history changes as requiring confirmation
  • Don't assume user intent
  • Default to safest option

4. Improve Stash Education

When user says "save my work":

  • Explain: "git stash saves UNCOMMITTED changes only, not commit position"
  • Suggest: "Would you like me to create a backup branch instead?"
  • Offer: "Or I can copy the entire folder as a backup?"

---

Workaround for Users

Add to your project's CLAUDE.md:

## GIT SAFETY RULE - CRITICAL

**NEVER use `git reset --hard` unless I explicitly say those exact words.**

For any request involving:
- "roll back"
- "go back"
- "restore"
- "revert"
- "undo"
- "look at old code"

ALWAYS use `git checkout <commit>` or `git checkout -b temp-branch <commit>` instead.

ALWAYS ask for confirmation before ANY command that:
- Changes HEAD position
- Modifies commit history
- Could lose uncommitted work
- Is marked as "destructive" in git documentation

When in doubt, ASK before executing git commands.

---

Additional Context

Similar Issues Reported?

User reports this is not the first time Claude has made questionable git decisions, but this is the first time it caused significant data loss.

User's Development Context

  • Professional software development
  • Billing customer for time
  • Cannot charge customer twice for same work
  • Data loss = direct financial impact

Git Expertise Level

User understands git basics but relies on Claude for advanced operations. User's old workflow (multiple folder copies) was safer for their use case, even if less "professional".

---

Follow-Up Requests

  1. Acknowledgment: Please confirm this report is received and being reviewed
  2. Timeline: Expected timeline for investigation and potential fix?
  3. Workaround: Any immediate configuration changes we can make to prevent recurrence?
  4. Notification: Please notify when this issue is addressed in a future release

Daily Follow-Up Requested: User requests daily status updates until resolution.

---

Contact Information

  • Reporter: Jeff Kelling
  • Email: jeff@dataintegrities.com
  • Project: Care Connect API at /Users/jeffk/dev/data-integrities/care-connect/api
  • Available for: Clarification, additional details, testing fixes

---

Attachments

Git Reflog Showing the Damage

882e618 HEAD@{0}: reset: moving to 882e618
35eb731 HEAD@{1}: reset: moving to 35eb731
35eb731 HEAD@{2}: reset: moving to HEAD
35eb731 HEAD@{3}: reset: moving to 35eb731
882e618 HEAD@{4}: reset: moving to HEAD
882e618 HEAD@{5}: commit: feat: Add requestTiming middleware with req/res.durationMS getters
71211e5 HEAD@{6}: commit: fix: Resolve tracker concurrency bug and file write callback issues
662c7d7 HEAD@{7}: commit: fix: Replace this.tracker with req.tracker across all controllers
42ca00c HEAD@{8}: commit: fix: Create per-request tracker to prevent concurrent request corruption
d63695e HEAD@{9}: commit: feat: Add capabilities endpoint and update version to 1.0.71
35eb731 HEAD@{10}: commit: refactor: Improve logging, fix session management, and clean up captures

Relevant CLAUDE.md Rules (Violated)

# ⚠️ CRITICAL WARNING ⚠️
## DON'T EVER RESTORE FROM GITHUB WITHOUT ASKING FIRST

Using `git checkout` or `git restore` commands will PERMANENTLY DELETE all uncommitted changes.
Always ask the user before running any git commands that modify files.

---

Report Status: ⏳ Awaiting Response
Priority: HIGH (Data Loss, User Trust, Business Impact)
Last Updated: 2026-01-09 14:45 CST

View original on GitHub ↗

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