openclaw - 💡(How to fix) Fix Slack channel subagent completion wake fails with source_reply_delivery_mode_mismatch while Slack remains healthy

Summary

On OpenClaw 2026.5.22, a Slack channel requester session can receive the user's message and keep the Slack channel probe healthy, but still fail to receive/wake subagent completion events.

The key failure signature is:

queue_message_failed reason=source_reply_delivery_mode_mismatch

This looks similar to the Discord-specific source_reply_delivery_mode_mismatch issue in #86232, but this reproduction is on Slack channel delivery with the latest 2026.5.22 release.

Environment

• OpenClaw: 2026.5.22
• Gateway: local loopback, reachable
• Channel surface: Slack channel
• Slack status during incident: enabled, configured, running, connected, health:healthy, works
• Provider/API path: openai / openai-responses
• Model: gpt-5.5
• Runtime shape: parent Slack session launched multiple repo-study subagent tasks

What happened

A Slack user asked the agent to check whether four repo-study tasks had completed. The agent had previously reported four tasks as running and said it would summarize after their completion events returned.

The gateway and Slack listener stayed alive, and Slack replies were still being delivered before the failure. However, when subagent completion events started arriving, the active Slack requester session could not be woken.

Sanitized timeline, local time UTC+8 on 2026-05-25:

18:13:16-18:13:18  Four repo-study subagent runs were accepted/started.
18:19:20-18:19:25  Slack replies were still being delivered normally.
18:23:02           Only one expected note file was written:
                   repo_study_storygen_atelier_2026-05-25.md
18:23:18           Subagent completion direct announce failed:
                   completion agent did not deliver through the message tool
18:23:20           Active requester session could not be woken for subagent completion:
                   queue_message_failed reason=source_reply_delivery_mode_mismatch
                   gatewayHealth=live
18:23:55           Same wake failure repeated for the same Slack requester session.
18:27:55-18:29:24  Other subagent completion direct announces failed with:
                   gateway request timeout for agent
18:29:51           Main Slack requester session stuck recovery aborted the embedded run:
                   activeWorkKind=embedded_run queuedCount=3
18:40:41           A later completion announce hit context overflow:
                   Context overflow: prompt too large for the model.

Live health check around the incident:

Gateway reachable.
Slack default: enabled, configured, running, connected, health:healthy, works

Actual behavior

• Slack received the user's message and the channel remained healthy.
• Subagent completion events failed to wake/deliver into the active Slack requester session.
• The main Slack session became stalled and was eventually aborted by stuck-session recovery.
• Follow-up completion attempts timed out or overflowed context.
• From Slack, the workflow looked like the agent acknowledged work but then stopped producing the expected summary.

Expected behavior

For Slack channel requester sessions:

• Subagent completion events should wake the correct requester session when the gateway is live and Slack remains healthy.
• source_reply_delivery_mode_mismatch should not silently block the requester-session completion path.
• If completion cannot be delivered, the user/operator should receive a visible terminal state or recovery message instead of a wedged Slack conversation.
• Completion delivery state should be preserved or recoverable so the parent can summarize completed work without manual filesystem inspection.

Impact

This breaks multi-agent / repo-study workflows over Slack:

• Completed or partially completed subagent work is not surfaced to the parent Slack conversation.
• The user has to manually ask whether tasks finished.
• The gateway may stay live and Slack may stay healthy, making this hard to diagnose as a channel-level problem.
• The failure can cascade into stuck-session recovery, context overflow, and later Responses continuation errors.

Related issues

This is related to, but more Slack-specific than:

• #44925: General subagent completion delivery reliability.
• #86232: Discord group chat source_reply_delivery_mode_mismatch; this Slack case has the same signature but a different channel surface.
• #86034: Media generation completion delivery can fail after successful generation.
• #84002: Slack continuation / Responses thinking_signature_invalid; in this incident, thinking_signature_invalid appeared later, after the requester-session wake path had already failed.

Notes

I intentionally omitted raw session files, local absolute paths, Slack channel IDs, auth names, and tokens from this report. I can provide more targeted sanitized log slices if useful.