Bug type

Behavior bug (incorrect output/state without crash)

Summary

In direct Telegram chats, the user sometimes receives a literal JSON-like message:

{"action":"NO_REPLY"}

This appears to be an internal silent-response control payload leaking into outbound user-visible messages.

Steps to reproduce

1. Field repro (real Telegram chat)

1. Open a direct Telegram chat with OpenClaw.
2. Send several low-content messages where the assistant may choose to stay silent (e.g. “ok”, “👍”, “got it”, or heartbeat-style checks).
3. Continue normal conversation for a few turns.
4. Observe that occasionally, instead of no output, Telegram receives:
   {"action":"NO_REPLY"}

2. Deterministic repro (recommended for devs)

This is the cleaner engineering repro:

1. Create a test session with Telegram adapter enabled.
2. Force assistant output into each of these forms:

• NO_REPLY (string sentinel)
• { "action": "NO_REPLY" } (object/action form)
• empty text + action metadata carrying NO_REPLY

3. Run through normal outbound routing pipeline (assistant → event translation → channel adapter).
4. Assert zero outbound user-visible messages for all three cases.
5. Current bug condition: object/action form gets serialized and delivered as literal text JSON.

3. Extra checks to include

• Retry with heartbeat prompt path and non-heartbeat path.
• Retry with direct chat vs thread/group context (if supported).
• Verify logs show suppression event, not send event.

Expected behavior

When the assistant intends to stay silent, the transport/router should suppress output entirely (or handle internal NO_REPLY semantics internally).
The end user should not see internal control payloads.

Actual behavior

Intermittently, Telegram receives a visible message containing:

{"action":"NO_REPLY"}

Channel / context

• Provider: Telegram
• Chat type: direct message
• Surface: Telegram
• Seen in normal conversational flow (non-heartbeat context as well)

Why this matters

• Confusing UX (looks like internal protocol/debug output)
• Breaks trust/quality expectations in user-facing chat
• Suggests a boundary issue between assistant control messages and channel delivery layer

Suspected technical area

Likely in one of these handoff boundaries:

1. Assistant output normalization (NO_REPLY sentinel handling)
2. Runtime event translation (internal action objects to channel payloads)
3. Telegram delivery adapter filtering
4. Fallback serialization path that forwards action objects when no text body is present

Suggested fix

• Enforce a strict outbound guardrail before channel send:
• Drop/suppress messages where payload is only internal NO_REPLY action/sentinel
• Never serialize internal action objects to user text
• Add regression tests for Telegram adapter and generic channel router:
• NO_REPLY (string sentinel) should produce no outbound message
• {"action":"NO_REPLY"} (object form) should also be suppressed
• Add structured logs/metrics when suppression occurs (for debugging) without exposing payload to users

OpenClaw version

2026.2.26

Operating system

win 11 pro

Install method

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response