In a shared multi-agent working tree, `git commit --amend` doesn't re-check HEAD, so it can silently rewrite a concurrent teammate's commit instead of the agent's own

What You Asked Claude To Do

(Context: Agent Teams session, multiple teammate agents sharing one non-worktree-isolated git working tree.) No explicit instruction was given for this specific action — the agent, on its own initiative, created a commit and then ran git commit --amend on what it believed was that same commit, solely to append a required tag to the commit message.

What Claude Actually Did

1. Agent A creates commit C1.
2. Between Agent A's git commit and its follow-up git commit --amend, a different teammate agent (Agent B) committed on top of C1, making its own commit C2 (parent = C1) the new HEAD.
3. Agent A's git commit --amend did not re-check HEAD before amending. --amend operates on whatever the current HEAD is, not on "the commit I personally just made" — so it rewrote Agent B's commit C2, keeping C2's file tree (byte-identical, verified after the fact — no data was lost) but discarding B's commit message and replacing it with A's own.
4. This was only caught because the team's shared project instructions already document a near-identical historical incident and rule ("in a shared working tree, commit only via explicit pathspecs, never blanket git add, because the staging area is shared") — but that rule's rationale didn't lead the agent to generalize the same caution to --amend, which has the identical shared-mutable-state hazard (it also silently operates on whatever HEAD/index currently is, not what the agent expects them to be).

Expected Behavior

Before running git commit --amend in any working tree that might be shared with other concurrent processes/agents, Claude should verify that HEAD is still the commit it believes it is (e.g. git rev-parse HEAD checked against the SHA it received from its own prior git commit) — the same verification discipline it already applies to plain git add/git commit in shared-tree contexts — and should refuse or warn rather than amend blindly if HEAD has moved.

Files Affected

Only git history/metadata was affected (a commit's message and parent linkage), not file contents — the amended commit's tree was byte-identical to the commit it replaced. No working-tree files were lost.

Permission Mode

Not applicable / not recorded for this specific action (git commands, not file edits).

Can You Reproduce This?

Yes, every time with the same prompt / setup — the race condition is deterministic given the described interleaving (two agents committing to the same non-isolated working tree in quick succession), though the timing of the interleaving that triggers it is not something a single prompt reliably controls.

Steps to Reproduce

1. Set up two Claude Code agents (e.g. Agent Teams teammates) sharing one plain git working tree (no worktree isolation).
2. Agent A commits (C1).
3. Before Agent A's next action, Agent B commits on top (C2, parent = C1).
4. Agent A, unaware C2 landed, runs git commit --amend intending to fix C1's message — it rewrites C2 instead, discarding Agent B's message.

Additional context

This may be better addressed as a product-level guardrail (warn or block git commit --amend in a shared working tree when HEAD has moved since the agent's own last commit) than as a model-behavior correction, since the same hazard applies to any agent that reasons about --amend as "my commit" rather than "whatever HEAD is".

Claude Code Version

2.1.239