[BUG] Claude carelessly deletes uncommited work by dropping git stash that failed to pop (commonly repeating pattern)
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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗