Problem

Background task completions (e.g. image_generate) were silently dropped for direct-message requesters under the MCP-bridged claude-cli runtime. The task completed and its side effects ran, but the user-requested media/text never arrived — the user got nothing until a later message re-triggered a normal turn.

Root cause

In sendSubagentAnnounceDirectly, the requester's captured completion origin can carry no deliverable channel: the MCP-bridged CLI runtime builds tools with an empty agentChannel, so the origin collapses to the internal webchat channel. stripNonDeliverableChannelForCompletionOrigin then strips it, leaving deliveryTarget.deliver = false.

With no deliverable target, the existing direct-delivery fallbacks (deliverGeneratedMediaCompletionDirect / deliverTextCompletionDirect) all no-op, and the woken requester-agent handoff turn — running under message_tool_only — isn't guaranteed to call the message tool. The result is a silent drop with no error.

(Native runtimes avoid this because they build tools per-turn with the live inbound origin. The last-mile delivery path itself is shared across all runtimes, so the fix lives at that shared layer.)

Fix

In sendSubagentAnnounceDirectly:

1. Backfill the completion origin from the requester session's persisted delivery context (deliveryContextFromSession(requesterEntry)) when the captured origin has no deliverable channel. This restores a real target so the existing fallbacks can fire.
2. Deliver generated media directly for DM targets when the requester-agent handoff fails — previously gated only on session-write-lock errors.

Real behavior proof

Behavior or issue addressed: A background image_generate completion to a Telegram DM was silently dropped — the generated image never reached the user until they sent another message. After the fix the completion delivers the image to the DM autonomously.

Real environment tested: Live OpenClaw gateway on the patched build, claude-cli runtime over the MCP bridge, real Telegram DM channel. User/bot IDs and meal content redacted.

Exact steps or command run after fix: In a real Telegram DM, sent a request that fires a background image_generate, then left the session idle (no further messages, no manual ping) and watched the gateway journal for the completion delivery.

Evidence after fix: redacted runtime log (2026-06-18) — the background completion wakes the idle session and delivers the image with no ping and no "delivery not confirmed" warning:

17:21:03 [telegram/inbound]    Inbound message telegram:<dm-user> -> @<bot> (direct)
17:21:04 [agent/cli-backend]   cli exec: trigger=user useResume=true        # turn fires background image_generate
17:21:36 [agent/cli-backend]   claude live session close: reason=restart    # session goes idle
            (~54s idle while the background image is generated)
17:22:30 [agent/cli-backend]   cli exec: useResume=false reuse=invalidated  # completion wakes a fresh turn (promptChars=11911)
17:23:20 [agent/cli-backend]   claude live session close: reason=restart
17:23:21                       [completion turn produces its reply + the generated image]
17:23:24 [telegram/send]       telegram outbound send ok chatId=<dm-user> messageId=1293 operation=sendPhoto   # delivered, no ping

Observed result after fix: the image (sendPhoto messageId=1293) was delivered to the DM autonomously, with no manual ping. Reproduced across multiple background image completions the same day (sendPhoto messageIds 1287 / 1293 / 1298 / 1304) — every one delivered with no reason=no_active_run drop and no completion delivery was not confirmed after successful generation warning.

Before evidence (optional): diagnosed 2026-06-16/06-17 (those daily logs have since rotated). The same background completion was silently dropped: reason=no_active_run, the fallback requester-agent handoff turn went private-final (never called the message tool under message_tool_only), and the runtime logged ... completion delivery was not confirmed after successful generation (emitted at src/agents/tools/media-generate-background-shared.ts:443). The user received nothing until a manual ping re-triggered a turn.

What was not tested: the active-session steered path (a completion landing in a genuinely active run) is intentionally unchanged — it stays delegated to that turn to avoid double-messaging a live conversation, so it was not separately exercised here.

Testing (supplemental)

• New regression test supplies no deliverable origin in any param and asserts delivery routes to the backfilled target. Negative-control verified: it fails if the backfill is removed.
• Full subagent-announce-delivery suite: 102 passing.

Notes

This intentionally does not change the active-session steered path (covered by does not also direct-run a queued active completion): a completion landing in a genuinely active run is still delegated to that turn, to avoid double-messaging a live conversation.

🤖 Generated with Claude Code