Summary

A Telegram group/topic reply from OpenClaw was delivered as a normal notification even though the generated message ended with notify=false. The notify=false marker appeared in the visible Telegram message body instead of being applied as delivery metadata.

This suggests an issue at the OpenClaw/Codex harness delivery boundary: either the harness has no supported silent-send metadata path for Telegram replies, or a supported notify=false convention is not being parsed/applied before the Telegram send.

Observed symptom

In a Telegram forum topic, OpenClawBot sent this completion/update message:

No interruption needed.

Current wake outcome for NHL-Top-5:

• main and develop are synced in the current probe.
• No stale local branches showed up in the current branch list.
• No open PRs were returned by the PR list check.
• The test probe still cannot run because pytest is not installed in this environment: ModuleNotFoundError: No module named 'pytest'.

notify=false

Despite the trailing notify=false, Telegram notified the user normally.

Expected behavior

If a message or completion path carries a silent notification intent, OpenClaw should either:

• send the Telegram message with Telegram Bot API disable_notification=true, or
• suppress the message entirely when the correct behavior is no user-visible reply, for example by honoring NO_REPLY in eligible group-chat contexts.

The delivery-control marker should not appear in the visible Telegram message body.

Actual behavior

• notify=false was rendered as literal text in Telegram.
• Telegram delivery was not silent.
• The message still produced a notification for the user.

Likely affected path

This may be specific to subagent/completion-delivery or wake/probe updates, because the message looked like an automated completion/status report rather than a direct user-requested answer.

The standing order in this environment says subagent completion events should be delivered immediately. That may be forcing a normal Telegram reply while bypassing any notification options.

Hypotheses

1. The Codex/OpenClaw harness supports no structured way for agent text output to request silent Telegram delivery.
2. There is an intended notify=false convention, but it is only appended to text and never parsed into delivery metadata.
3. A subagent completion, wake, or automated status-delivery path bypasses the normal Telegram delivery options and always sends loud messages.
4. The Telegram adapter does not map an internal notify: false flag to Telegram Bot API disable_notification: true.

Potential fix options

Option A: Add/repair structured delivery metadata

Represent notification behavior as structured metadata, not text. For Telegram, map notify: false or equivalent to disable_notification: true in the outbound adapter.

Acceptance checks:

• A reply with silent intent is sent with disable_notification=true.
• The literal string notify=false is not included in the message body.
• The behavior works for direct agent replies and completion/wake delivery paths.

Option B: Parse and strip legacy marker before delivery

If notify=false is already an established convention, strip a trailing standalone marker and convert it to delivery options before sending.

Acceptance checks:

• A trailing standalone notify=false is never visible to Telegram users.
• The Telegram send receives disable_notification=true.
• Non-control text containing notify=false is not accidentally modified.

Option C: Make automated completion reports silent by default in group topics

For background wake/probe/subagent completion reports in Telegram groups/topics, default to silent delivery unless explicitly escalated.

Acceptance checks:

• Background completion reports in group topics are delivered silently.
• Direct user replies are unaffected unless explicit silent intent is set.
• Urgent/error paths can still opt into normal notification delivery.

Option D: Suppress low-value completion reports in group contexts

When a completion event is informational and not directly requested, allow NO_REPLY/suppression instead of forcing a Telegram message.

Acceptance checks:

• Non-actionable background completions can be suppressed.
• User-requested completions still get a visible response.
• Suppression rules do not hide failures or requested results.

Notes

This is probably not an LLM/model behavior issue by itself. The visible notify=false strongly points to metadata being serialized into plain text or not consumed by the delivery layer.