Build1 publisher2 min readPublished
Claude Code parent session's git rebase --skip erased 25 rows its subagent never committed
Running git rebase --skip in a parent Claude Code session erased 25 uncommitted rows its subagent wrote to the same working tree, per a dev.to postmortem. The rows were never staged, so git had no copy to restore.
The Engineer · Build desk
What happened
- The team got the rows back only because the subagent had left a copy outside the repository, and the restore commit shows +37 -12 on that file.
- The loss reproduces in a throwaway repository with no Claude Code involved, using three echo lines as the subagent while a rebase conflict is open.
- Running git rebase --abort on an identical setup also put the tracked file back to its single original line.
- Only git rebase --quit kept the appended rows, and it left conflict markers in the file with HEAD detached on the upstream commit.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure A subagent's success report covers only the moment it wrote the file, so an orchestrator that counts work as done before it is committed or copied out of the tree can lose it to the parent's next git command.
- decision Teams running parallel agents in one repository now have to decide where uncommitted work lives before any session syncs: in a separate working tree, or behind a check that runs before rebase.
- constraint Spotting the danger mid-conflict still leaves manual repair work, because the one exit that keeps the edits also gives up the branch position.
The data is lost at checkout. According to the postmortem, --skip makes the merge backend check out the state it wants to continue from, and anything in a tracked file that is not part of that state is overwritten [12]. The 26 media files the subagent rendered were untracked, and they survived the skip [2]. Afterwards, git fsck --lost-found listed one dangling commit and one dangling tree. Both belonged to the skipped local commit [7].
The manual would not have warned anyone. On git 2.50.1 the complete --skip entry reads: "Restart the rebasing process by skipping the current patch." [10] The --quit entry does describe its effect on the tree: "The index and working tree are also left unchanged as a result." [11] The team measured everything on git 2.50.1 (Apple Git-155) and Claude Code v2.1.278 [15].
The reproduction is the best engineering in the post. It cuts the incident down to a script anyone can run in a throwaway repository [5], and its two git status listings show the whole failure. With the conflict open, git showed UU README.md, M stock.jsonl, an untracked PNG, and stock.jsonl at four lines. After --skip it showed only the PNG, with the file at one line and an empty stash list [6].
I would not use --autostash as the guard. Its manual entry says the stash is created "before the operation begins" [13]. The subagent wrote its rows after the conflict had already stopped the rebase [1]. Read literally, that means a stash taken when the pull started would hold none of the 25 rows [1]. The postmortem quotes the autostash entry but does not report testing it against this case [13].
In my context, where more than one agent can write to a repository at the same time, I'd give each writer its own working tree. The failure needs a second party editing a tracked file in the same tree while a conflict is open [4]. Separate trees remove that condition. For teams that keep a shared tree, the postmortem offers a guard script to run in place of a bare git pull --rebase [14]. Such a guard has a clear signal to check. Before anyone typed --skip, the subagent's file showed as M next to the UU conflict [6]. I'd expect a check that refuses --skip or --abort while any tracked file outside the conflict shows M to have caught this one.
What to watch
- A tested result for --autostash against edits written after a rebase conflict opens, which the postmortem quoted but did not run.
- Whether the git manual's --skip entry is revised to say that tracked working-tree changes are overwritten, as the --quit entry already describes its own effect.
- Whether Claude Code changes how subagents share the parent session's working tree after reports like this one.