[Bug] Agent chains `git stash pop` after failed `git stash push`, corrupting unrelated user stash
Bug Description
Bug: agent chained git stash pop after a git stash push that silently failed, popping the user's unrelated stash and polluting the working tree.
The agent ran git stash push -- fileA fileB ; <tests> ; git stash pop in one line to verify pre-change spec behavior. fileB was a new untracked file, so git stash push -- <paths> aborted wholesale (pathspec did not match any file(s) known to git) and created no stash. Because the commands were ;-chained rather than &&-gated, git stash pop still ran and popped/dropped a pre-existing unrelated user stash (a -u stash with tracked + ~48 untracked files), dumping it into the tree. The agent then reported it as having "popped/dropped cleanly."
Suggested guardrails: (1) when a stash/pop verification pattern is used, gate the pop on push success (&& / check a new stash ref actually appeared); (2) prefer git worktree for pristine-state checks; (3) parse the push output for the pathspec did not match / No local changes to save cases before ever calling pop.
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.202
- Feedback ID: 10fc2854-0f6f-4114-b60e-ff2eda4a7c32
Errors
[]