Feature request: stamp subagent task-completion notifications with the HEAD SHA at measurement time

Feature request: stamp subagent task-completion notifications with the HEAD SHA at measurement time

Version: Claude Code 2.1.251 (macOS)

Problem

When a subagent (Agent tool / teammate) finishes, the lead receives a task-completion notification. In multi-agent sessions where the working tree keeps moving, we observed completed agents being re-notified repeatedly — and in several cases the re-delivered notification carried a test verdict measured against code that was already 3 commits stale. A lead reading "PASS" in that notification has no mechanical way to tell whether it was measured against the current HEAD or a tree that has since changed.

The only defence today is lead discipline (re-derive the SHA from the agent's transcript, or re-run the gate). That is exactly the kind of check that gets skipped under load, and the failure mode is silent: a green that is stale looks identical to a green that is current.

Proposal

Include, in the task-notification payload delivered to the lead (and ideally in the SubagentStop hook input), the repository HEAD SHA of the agent's cwd at the moment the agent finished — e.g. measured_at_head: "1a2b3c4" (plus a dirty: true|false flag). Then:

• a lead (or a hook) can reject a verdict mechanically when measured_at_head != git rev-parse HEAD;
• re-delivered notifications become self-describing rather than ambiguous;
• no behavioural change for single-agent sessions (field is informational).

If a stable identifier for the notification itself (a monotonic id or first-delivery timestamp) were also included, duplicates could be deduplicated on the receiving side.

Workaround we use

Our agent contracts now require gate agents to write Verdict: PASS @ <short-sha> on the line above the verdict token, and the lead treats a mismatch with HEAD as "no verdict". It works, but it relies on every agent remembering, and it cannot fix notifications that the harness re-delivers on its own.

Why it matters

Any workflow that merges on a subagent's green — which is what subagent-driven development encourages — is one re-delivery away from merging on stale evidence. Stamping the SHA makes the notification a receipt instead of a claim.