Spots 
On 2026-09-15 a Claude Code subagent appended 25 post drafts to a tracked file in our working tree while the parent session was resolving a rebase conflict in the same tree. The parent ran git rebase --skip. All 25 rows were gone; only the 26 untracked media files the subagent had rendered survived. We got the rows back from a copy the subagent had left outside the repo, and the restore commit shows +37 -12 on that one file.
This is a failure story about two things sharing one working tree: a Claude Code subagent and its parent. Neither did anything unusual. The subagent edited a file and reported success. The parent finished a rebase the way the git hint suggests. The combination deleted work that had never been committed, and git could not bring it back, because the content had never been turned into an object.
Below is the timeline reconstructed from git history and our run log, a five-minute reproduction you can run in a throwaway repository, what the git manual says and does not say about --skip, and a guard script you can run instead of a bare git pull --rebase. Claude Code v2.1.278 and git 2.50.1 (Apple Git-155) were used for everything measured here. Five minutes to see it yourself
You do not need Claude Code for this part. You need a conflict in progress and a second party that edits a tracked file while the conflict is open. The "subagent" below is three echo lines. The two status listings are the whole story:
The UU conflict is resolved by dropping the local commit, which is what --skip is for. The M stock.jsonl line, the subagent's work, is gone. The ?? file is still there. git stash list is empty, so nothing was parked anywhere. git fsck --lost-found afterwards lists one dangling commit and one dangling tree; both belong to the skipped local commit. The three appended rows never reached the index, so no blob was ever written for them. There is nothing in the object database to recover.
git rebase --abort behaves the same way in this respect. I ran it on an identical setup and the file went back to one line. The only exit that left the tree alone was git rebase --quit, which the manual documents as leaving "the index and working tree ... unchanged". After --quit the four rows and the conflict markers were both still there, but HEAD was detached on the upstream commit, so it is an emergency exit, not a fix. What the manual says about --skip From git rebase --help on git 2.50.1: --skip Restart the rebasing process by skipping the current patch. --skip Restart the rebasing process by skipping the current patch.
That is the complete entry. It does not say the working tree is reset. The behaviour above is what "restart the rebasing process" means in practice: the merge backend checks out the state it wants to continue from, and anything in a tracked file that is not part of that state is overwritten. Compare the entry for --quit, which does spell out what happens to the tree:
--quit Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result.
--quit Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result. And the entry for --autostash:
--autostash, --no-autostash Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.
On 2026-09-15 a Claude Code subagent appended 25 post drafts to a tracked file in our working tree while the parent session was resolving a rebase conflict in the same tree.