openclaw - 💡(How to fix) Fix Slack interactive reply button clicks not routed to originating thread session [1 comments, 1 participants]

Bug Description

When an agent sends a Slack message with interactive buttons (via message tool with interactive parameter), the button click events are received by the gateway and enqueued as system events, but they are not delivered to the agent session that sent the original message.

Steps to Reproduce

1. Agent sends a message with interactive buttons to a Slack thread:

   message(action=send, channel=slack, target=channel:XXXXX, message="Pick one", interactive={blocks: [{type: "buttons", buttons: [{label: "A", value: "a"}, {label: "B", value: "b"}]}]}, replyTo=threadTs)

2. User clicks a button in Slack
3. Gateway logs show the interaction is received:

   [slack] interaction action=openclaw:reply_button:1:1 type=button user=UXXXX channel=CXXXX

4. enqueueSlackBlockActionEvent is called, and enqueueSystemEvent queues the event
5. But the agent session never receives the button click — no system event is prepended to the next prompt

Expected Behavior

The button click should be delivered to the originating agent session as a system event, containing:

• Which button was clicked (value)
• Who clicked it (user ID)
• The original message context (thread_ts, message_ts)

Analysis

In interactions.block-actions.ts, the session key is resolved via resolveSlackSystemEventSessionKey. The issue appears to be that the resolved session key for the interaction does not match the active thread-bound session that originally sent the interactive message.

Environment

• OpenClaw version: 2026.3.28 (commit f9b1079)
• Channel: Slack (Socket Mode)
• Config: channels.slack.capabilities.interactiveReplies: true

Workaround

Currently, agents can still use interactive buttons for visual presentation, but cannot programmatically react to button clicks. Users must type their selection as a follow-up text message instead.