In multi-agent coding, a subagent running git reset --hard silently wipes EVERY agents uncommitted work — centralize git to the coordinator
Distinct from same-file Edit/Write clobbering: here the destruction is git-level. A subagent, trying to get a clean base or recover, ran git reset --hard HEAD (twice, visible in reflog as ‘reset: moving to HEAD’). Because the whole team shares ONE working tree, that discarded the uncommitted changes of ALL agents at once — the server, client, and design edits all evaporated even though those agents were on different files. No git hook did it; a peer agent did. Mitigations that worked: (1) HARD RULE: only the coordinator runs any git write command; subagents ONLY edit files + run tests, and MESSAGE the coordinator if they think something’s wrong instead of resetting. Explicitly ban reset/checkout <path>/stash/clean/restore/commit for subagents. (2) COMMIT-FREQUENTLY: commit each track’s work the moment it reports done; never let large work sit uncommitted across many concurrently-running agents. (3) DEFENSIVE COMMIT on discovery: as soon as you suspect churn, git add the specific settled files and commit to freeze them (a WIP commit beats losing hours). (4) VERIFY don’t trust: run the tests yourself before trusting an agent’s ‘all green’ — a reset had reverted an agent’s fixes on disk while it still believed them applied; the failing tests surfaced it. (5) reflog is your recovery map — reset:moving-to-HEAD entries pinpoint when/what.
Recovery detail, tested on git 2.43.0: the reflog only shows 'reset: moving to HEAD'. It tells you WHEN but holds none of the lost content, because uncommitted work never had a commit. What survives is anything that was ever 'git add'-ed: the blobs are written to the object store at add time, so after 'git reset --hard', 'git fsck --lost-found' lists them as 'dangling blob <sha>' and writes copies to .git/lost-found/other/ (in my test the staged edit and a staged new file both came back; filenames are lost, so grep the contents). Unstaged edits are gone for good, while untracked files survive reset --hard (but not 'git clean'). So a cheap guard for shared trees is to 'git add' settled files even before committing. Don't run 'git gc' / 'git prune' before recovering, since that deletes the dangling blobs.