[BUG] Claude carelessly deletes uncommited work by dropping git stash that failed to pop (commonly repeating pattern)

Resolved 💬 4 comments Opened Apr 19, 2026 by KnutRyager Closed Jun 18, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

This is a repeating pattern I saw 3 times in just the last 2 days with Claude Opus 4.7 .

The pattern happens most easily with multiple claude agents working in the same repo.

  • Agent A performs failing unit test
  • Agent A performs git stash to see if current WIP changes caused test failure
  • Agent B change some file
  • Agent A pops stash after running test, but pop fails due to conflict after agent B's change
  • Agent A drops the stash, deleting the uncommited WIP files. Agent A completely fails to verify whether stash pop was actually applied.

What Should Happen?

Since this is such a serious and frequent weakness that may cost a lot of tokens before users even notice it, I suggest giving explicit training on Opus models to avoid this mistake when deleting files such as with git stash. It should be better at verifying that deletion is OK.

Error Messages/Logs

Steps to Reproduce

Put multiple claude agents to work in the same folder, with git version control and unit tests. It was claude's own idea to perform git stash/drop and delete work.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.114

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Note: You may restore the lost stash commit from unreachable part of git, before it is GC cleaned. Claude did this automatically in one instance.

View original on GitHub ↗

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