Agent tool task-notification can report status:completed while the subagent's underlying work is still running

Summary

Background Agent tool dispatches have repeatedly delivered a task-notification with status: completed while the spawned subagent's own final message indicates its work was still in progress or unfinished. This isn't isolated to one subagent type — it has recurred across different custom subagents (a git-history-rewrite agent, coding agents, and others), suggesting a structural gap rather than a one-off prompt issue.

Clearest reproduction

• Dispatched a background subagent to run a multi-step git history rewrite on a ~14GB repo, including git gc --prune=now --aggressive as one step.
• The subagent ran the long gc command, then ended its turn with a message stating the gc was still running and the (destructive) force-push step had NOT happened yet.
• The task-notification delivered to the parent session nonetheless reported status: completed.
• Only by manually reading the subagent's full transcript (not trusting the notification's status field) was it discovered the force-push had not executed.
• No further notification ever arrived — the Agent tool call had already resolved, so nothing remained queued to fire once the operation actually finished.

Impact

This breaks the trust model for orchestration: a parent session cannot rely on status: completed to mean the requested work actually finished. For long-running or destructive operations specifically, this risks acting on stale assumptions (e.g. believing a rewrite+push succeeded when it hadn't), and in practice has required the user to manually prompt "status?" to get the orchestrator to go check.

Suspected mechanism

The notification appears to fire when the subagent's own turn/response stream ends, not when the operation(s) it started have verifiably finished. There is no way to distinguish "the subagent's turn ended" from "the requested task is verified complete" at the notification level, and if a subagent backgrounds or otherwise doesn't block on a long command before ending its turn, nothing bridges that gap.

Suggested fix

• Expose a distinction at the notification level between "turn ended" and "task verified complete" (e.g. surface the subagent's own final-message sentiment/status rather than a blanket completed).
• And/or: don't resolve the parent Agent tool call as complete while a foreground command the subagent started is still executing.

Workaround in use

Mitigated at the prompt level with a standing instruction applied to every background agent dispatch: run long commands in the foreground, verify real state immediately before reporting done, and explicitly flag "still running" if a turn must end early. This reduces the blast radius but doesn't fix the underlying notification semantics.