Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [Bug] Claude Code destructively overwrites unstaged changes with `git checkout <ref> -- .` [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55024•Fetched 2026-05-01 05:48:13
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
inwoodevinwoodev
Participants
github-actions[bot]github-actions[bot]inwoodevinwoodev
Timeline (top)
labeled ×5commented ×1

Error Message

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/james/.local/share/claude/versions/2.1.123 (expected in multi-process scenarios)\n at x86 (/$bunfs/root/src/entrypoints/cli.js:2769:2177)\n at Jw8 (/$bunfs/root/src/entrypoints/cli.js:2769:1257)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-04-30T13:44:34.570Z"}]

Fix Action

Fix / Workaround

Bug Description Destructive git checkout <branch> -- . wiped unstaged WIP across 14 files during a code review session.

What happened: While helping me code-review a feature branch, Claude ran git checkout origin/<feature-branch> -- . inside my working tree (which was on a different branch with 14 unstaged modified files). The command silently overwrote every file with the feature branch's content. Then it ran git checkout HEAD -- . to "restore," which only reset to the current branch's HEAD — the unstaged WIP was destroyed. None of it had been git-added or stashed, so no recoverable blobs.

Why it happened: The model reached for a destructive command to "look at" another branch's files when read-only alternatives (git show <ref>:<path>, git worktree add) would have been correct.

Suggested mitigations:

  1. Treat git checkout <ref> -- . (and -- <pathspec> with broad globs) and git restore --source=<ref> . as destructive when the worktree has unstaged/untracked changes — require confirmation.
  2. The system prompt already warns about reset --hard, force push, etc., but the checkout <ref> -- . foot-gun is not on that list. It should be.
  3. Default to git show <ref>:<path> or worktree creation when the intent is "read another branch."

Impact: Significant uncommitted engineering work destroyed. fsck dangling blobs, APFS snapshots, Time Machine, editor autosave — all returned nothing. Only remaining hope was the editor's in-memory buffer.

Environment: macOS, Opus 4.7 (1M context).

Code Example

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/james/.local/share/claude/versions/2.1.123 (expected in multi-process scenarios)\n    at x86 (/$bunfs/root/src/entrypoints/cli.js:2769:2177)\n    at Jw8 (/$bunfs/root/src/entrypoints/cli.js:2769:1257)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-30T13:44:34.570Z"}]
RAW_BUFFERClick to expand / collapse

Bug Description Destructive git checkout <branch> -- . wiped unstaged WIP across 14 files during a code review session.

What happened: While helping me code-review a feature branch, Claude ran git checkout origin/<feature-branch> -- . inside my working tree (which was on a different branch with 14 unstaged modified files). The command silently overwrote every file with the feature branch's content. Then it ran git checkout HEAD -- . to "restore," which only reset to the current branch's HEAD — the unstaged WIP was destroyed. None of it had been git-added or stashed, so no recoverable blobs.

Why it happened: The model reached for a destructive command to "look at" another branch's files when read-only alternatives (git show <ref>:<path>, git worktree add) would have been correct.

Suggested mitigations:

  1. Treat git checkout <ref> -- . (and -- <pathspec> with broad globs) and git restore --source=<ref> . as destructive when the worktree has unstaged/untracked changes — require confirmation.
  2. The system prompt already warns about reset --hard, force push, etc., but the checkout <ref> -- . foot-gun is not on that list. It should be.
  3. Default to git show <ref>:<path> or worktree creation when the intent is "read another branch."

Impact: Significant uncommitted engineering work destroyed. fsck dangling blobs, APFS snapshots, Time Machine, editor autosave — all returned nothing. Only remaining hope was the editor's in-memory buffer.

Environment: macOS, Opus 4.7 (1M context).

Environment Info

  • Platform: darwin
  • Terminal: iTerm.app
  • Version: 2.1.123
  • Feedback ID: 3eae7ba8-9efd-45c2-a6de-62ba3fd66d9c

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/james/.local/share/claude/versions/2.1.123 (expected in multi-process scenarios)\n    at x86 (/$bunfs/root/src/entrypoints/cli.js:2769:2177)\n    at Jw8 (/$bunfs/root/src/entrypoints/cli.js:2769:1257)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-30T13:44:34.570Z"}]

extent analysis

TL;DR

To avoid data loss, treat git checkout <ref> -- . as a destructive command when the worktree has unstaged/untracked changes and require confirmation.

Guidance

  • When using git checkout <ref> -- . or git restore --source=<ref> ., be cautious of overwriting unstaged changes; consider using git show <ref>:<path> or git worktree add for read-only alternatives.
  • Before running potentially destructive Git commands, ensure all important changes are committed, stashed, or safely stored to prevent data loss.
  • Review the Git command warnings and consider adding git checkout <ref> -- . to the list of commands that require confirmation to prevent accidental overwrites.

Example

No specific code snippet is provided as the issue focuses on Git command usage and workflow rather than code.

Notes

The provided error message seems unrelated to the main issue of data loss due to git checkout <ref> -- . and may be a separate concern.

Recommendation

Apply workaround: Use git show <ref>:<path> or git worktree add for read-only access to other branches to avoid overwriting unstaged changes. This approach prevents accidental data loss and is a safer alternative to git checkout <ref> -- ..

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#tokenizer error#prompt formatting#chain error#conversation history#tool integration

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING