Task-tool subagents complete work but skip explicitly-instructed final delivery steps (push/PR) ~20% of the time
Environment
- Claude Code v2.1.216, Linux (WSL2, kernel 6.6.114)
- Models: Opus 4.6 / Fable 5 (observed on both)
- Pattern observed across ~15 Task-tool (subagent) dispatches in one working day
Bug
Subagents dispatched via the Task tool reliably complete the substantive work of a multi-step task (code, tests, verification, commit) but then omit the final, explicitly-instructed delivery steps — git push, opening a PR, enabling auto-merge — roughly 1 in 5 runs. The agent ends its run with a confident final summary as if the task were complete, while the work sits committed on a local branch that nothing references.
Reproduction shape
A prompt of the form:
1. Implement X in repo A; commit; push; open PR; enable auto-merge. 2. Implement the companion change in repo B (separate worktree/branch); commit; push; open PR; enable auto-merge.
Observed failure modes, in decreasing frequency:
- Second-leg decay: leg 1 is delivered end-to-end (pushed, PR opened, auto-merge armed) but leg 2 stops at the local commit. The final report often describes leg 2 as done.
- Terminal-step starvation: on long single-leg tasks, everything through
git commithappens, then the agent emits its summary without push/PR — the implicit definition of "done" slides from delivered to artifact exists. - Over-generalized caution: prompts that contain hard rules about pushing in other contexts (e.g. "repo C must only be pushed with credential Y") appear to increase the chance the agent parks before ANY outward-facing step, including the explicitly-permitted one.
Expected
If the prompt's numbered instructions include push/PR as explicit steps, the agent either performs them or states clearly in its final message that it did not and why. The silent-park + "done" summary combination is the damaging part: a supervisor that trusts the summary loses the work; one that doesn't must re-verify every claim.
Workaround
A supervising session treats every subagent completion as unverified: checks git log / PR state against the claimed outcome and performs the missing delivery steps itself (the work is always intact — only the last mile is dropped). This works but defeats much of the point of delegation.
Suggestion
The strongest lever seems to be the final-message contract: if subagents were required to emit a structured completion checklist against their numbered instructions (done / not-done per step) rather than free-form summaries, the silent-park case would at least become visible, and might self-correct — writing "step 5: push — NOT DONE" plausibly prompts the model to just do it.