claude-code - 💡(How to fix) Fix Dispatch beta: dispatcher fails to proactively send_user_message after worker completion (silent until user prompts)

Summary

In Cowork Dispatch beta, the dispatcher agent fails to proactively call SendUserMessage after worker (Task tool) completion. The dispatcher remains silent until the user explicitly prompts ("Report", "回報", "what's the status?"), even though the dispatcher's system prompt and CLAUDE.md explicitly require proactive reporting and periodic pulse updates.

This is distinct from #40178 / #40179 / #40281 / #40713 / #46093 — those are transport/delivery layer bugs (SendUserMessage tool not loadable, response not relayed to UI). In this report, the tool is loadable; the dispatcher simply doesn't choose to invoke it after worker completion. The root cause is in the agent loop's discipline / heuristics, not the messaging transport.

This is also adjacent to (but distinct from) #57523 (Dispatch beta: enable user-defined PreToolUse / output hooks for SendUserMessage) — that issue asks for a way for users to enforce reporting via hooks; this issue asks for the SDK to enforce reporting natively, since user-side hook enforcement is currently blocked.

Environment

• Cowork desktop app (current build, 2026-05-09 sessions)
• OS: Windows 11
• Configuration: dispatcher subagent + parallel general-purpose worker subagents
• System prompt explicitly instructs proactive SendUserMessage after each Task tool result and on a pulse cadence

Steps to Reproduce

1. Open Cowork Dispatch with a dispatcher agent whose system prompt mandates: "After every worker completion, immediately SendUserMessage with a status update. Send pulse updates every N minutes during long-running work."
2. Dispatch a worker task (e.g., research, file editing, vault operations) that takes 2–10 minutes.
3. Worker completes; Task tool result returns to dispatcher.
4. Observe: dispatcher receives the tool result, often silently logs internal reasoning, but does not invoke SendUserMessage unless the user manually types a prompt.

Reproduced ≥5 times in a single 2026-05-09 session, including:

• Worker completes vault file edit → no proactive report; user types "回報" → dispatcher then summarizes.
• Worker finishes web research → no proactive report; user types "Report" → dispatcher relays findings.
• Multi-step multi-worker task → no pulse updates between worker dispatches; user types "目前進度?" each time.

Expected Behavior

When a Task tool result returns to the dispatcher (worker completion), the dispatcher should:

1. Within the same turn (no further user prompt), invoke SendUserMessage with a concise status update (worker finished / outcome / next planned step).
2. On long-running multi-worker pipelines, send pulse updates at a deterministic cadence (e.g., every 2–5 minutes or every N tool calls), per the spec in the dispatcher's system prompt.

System-prompt-level instructions like "use proactively" / "report after every worker completion" should be honored consistently across turns.

Actual Behavior

• After worker completion, dispatcher returns a turn that contains internal tool calls (TaskList, Read, etc.) but no SendUserMessage.
• Conversation appears frozen from the user's perspective until they type a new message.
• Pulse updates during long pipelines are skipped entirely — there is no observable cadence.
• User must repeatedly prompt "Report" / "回報" / "status?" to extract worker results, defeating the point of dispatch (run async without babysitting).

This matches the published architectural reality: per the Claude Code Sub-agents docs, Task returns the worker's final message verbatim to the parent, but whether the parent then calls SendUserMessage is left entirely to model judgment. There is no SDK-level guarantee that worker completion → user-visible message. In practice, model attention drifts off the "proactive reporting" instruction when the dispatcher's context fills with worker outputs, internal reasoning, and tool call traces.

Root Cause Hypothesis

1. Attention drift on soft instructions. Proactive reporting is encoded as a system prompt instruction ("use proactively"). The Agent SDK is turn-based: the dispatcher decides each turn what to do based on context. As context fills with tool results and reasoning traces, the priority of "send a status message" decays relative to "continue working / dispatch next worker." Same root cause as #57523 (PreToolUse audit drift) — model self-discipline is unreliable for cross-turn behavioral contracts.

2. No deterministic trigger. The SDK has no built-in event hook of the form "Task tool result received → emit SendUserMessage with a summary." The closest mechanisms — Stop hooks, SubagentStop hooks — either don't fire reliably for subagents (#33049) or cannot bridge context to the parent (#5812, closed as not planned).

3. User-side hook workaround is blocked in Dispatch. Per #57523, the Dispatch sandbox does not mount user-defined PreToolUse / output hooks, so users cannot patch this themselves at the harness layer.

The cumulative effect: there is no reliable path — neither model self-discipline nor user-side hooks — to enforce "worker completion → user-visible status message." Dispatch operators are forced to manually poll, which negates the async value proposition of Dispatch.

Suggested Fixes

Option A (preferred) — SDK-level deterministic trigger

After every Task tool result returns to the dispatcher, the SDK injects a system-level instruction or auto-emits a templated SendUserMessage containing the worker's final message (or a configurable template). This makes worker completion → user-visible message a hard contract, not a model preference. Configurable via dispatcher config (on/off, template, dedup).

Option B — Pulse-update deterministic trigger

SDK emits a pulse SendUserMessage every N minutes / every M tool calls / every K worker completions during a dispatch session, based on dispatcher-provided cadence. Removes the need for the model to remember to send updates.

Option C — Surface user-defined hooks to Dispatch sandbox (closes #57523 dependency)

Allow users to register a PostToolUse hook on Task tool calls that emits SendUserMessage deterministically. This is the same fix requested in #57523 but framed for the proactive-reporting use case. Less preferred than A/B because it pushes the burden onto every dispatch user.

Option D — Cowork-platform-layer push notification on worker completion

Independent of the dispatcher's behavior, Cowork emits a platform-layer notification ("Worker X finished — open Dispatch to see results") when a Task tool returns. Acceptable as a partial fix; doesn't replace in-thread reporting, but at least prevents users from missing completion entirely.

Impact

• Production MSP / vault-operations workflows depend on async dispatch to free up operator attention. Without proactive reporting, every multi-worker pipeline degrades to manual polling (every 1–2 minutes), wiping out the dispatch productivity gain.
• Combined with #57523 (user can't enforce via hooks) and #1770 (no parent-child observability) and #5812 (closed not planned), users have no remediation path.
• Compounds with already-known Dispatch reliability issues (#40178 / #40958 / #51389): even when transport works, model discipline doesn't, so the user perceives a dead session.

References

• #1770 — Parent-Child Agent Communication and Monitoring (still open)
• #5812 — Hooks bridge between Sub-Agents and Parent (closed as not planned)
• #33049 — Subagent Stop hook does not fire (confirmed bug)
• #40178 / #40179 / #40281 / #40358 / #40430 / #40713 / #40958 / #46093 / #51389 — Dispatch transport/delivery layer issues (distinct from this issue)
• #57523 — Dispatch beta: enable user-defined PreToolUse / output hooks for SendUserMessage (related root-cause: attention drift + no user-side hook enforcement path)
• Internal vault research: 04.Archives/研究封存/研究-Dispatcher proactive reporting 限制與解法_2026-04-29.md

Attachments / Logs

Available on request: session transcripts from 2026-05-09 showing 5+ instances within a single session of dispatcher silently completing a worker and not emitting SendUserMessage until user-prompted.