Summary

When queue mode is set to steer, a user message that arrives during an active heartbeat run gets injected into that run. If the agent produces HEARTBEAT_OK (indicating no action needed) followed by a real response to the user's message, the outbound delivery appears to suppress the user-facing response along with the heartbeat ack.

Steps to reproduce

1. Configure queue mode as steer (e.g., messages.queue.mode: "steer")
2. Configure a heartbeat with a short interval
3. Send a user message on Telegram within a few seconds of a heartbeat firing
4. The heartbeat run receives the steered user message
5. Agent responds to the heartbeat with HEARTBEAT_OK, then responds to the user's actual question
6. User never receives the response to their question

Expected behavior

The agent's response to the user's message should be delivered to the user, even when the heartbeat portion of the same run produces HEARTBEAT_OK.

Actual behavior

The user receives no response. The agent's reply is visible in the session transcript (with correct timestamps showing it was generated), but it never arrives on the channel. The user has to send a follow-up message to get a response.

Hypothesis

The HEARTBEAT_OK discard logic may be suppressing the entire outbound delivery for the run, including the steered response that follows it. When steer injects a user message into a heartbeat run, the run produces two logical responses (heartbeat ack + user reply), but the discard logic treats the whole run as a heartbeat no-op.

Workaround

Switching to collect mode avoids the issue, since the user message queues as a separate followup turn rather than being injected into the heartbeat run.

Environment

• OpenClaw version: latest npm
• Channel: Telegram
• Queue mode: steer
• OS: Linux (Docker/VPS)