openclaw - 💡(How to fix) Fix [Bug]: internal completion/announce payloads can leak raw runtime metadata into user chat [1 participants]

Summary

OpenClaw sometimes delivers raw runtime/internal completion payload text into end-user chat instead of rewriting it into normal assistant voice.

This appears to be a shared failure boundary across:

• isolated cron announce deliveries
• subagent completion announces
• other runtime-generated follow-up/completion events that use the same announce/rewrite path

This does not look Telegram-specific and does not appear limited to one cron/job prompt.

Observed behavior

Instead of sending only the intended user-facing message, the user occasionally sees internal/plumbing-style text such as:

• file paths used during task execution
• routing labels like Message for Telegram → Han (id ...)
• runtime/internal context wrappers
• completion-event framing text
• subagent/completion metadata blobs

Example of leaked user-visible text from a wind-down reminder flow:

Wrote the latest wind-down message to:
~/.openclaw/workspace/mission-control/cron-outputs/wind-down-nudge-latest.md

Message for Telegram → Han (id 8577201933):
🌙 10pm. Ease into shutdown mode — dim the lights, put the screens away, and start getting ready for bed.

Expected user-visible message was only:

🌙 10pm. Ease into shutdown mode — dim the lights, put the screens away, and start getting ready for bed.

Separate sessions also showed raw internal event wrappers in-thread, e.g. payloads shaped like:

• OpenClaw runtime context (internal): This context is runtime-generated, not user-authored
• [Internal task completion event]
• completion content that should have been rewritten/summarized before delivery

Why this looks like an OpenClaw core bug

The docs explicitly describe a rewrite/sanitization boundary for completion announces:

Subagents docs

docs/tools/subagents.md says the completion handoff includes internal metadata and a delivery instruction to:

• rewrite in normal assistant voice
• not forward raw internal metadata

It also says:

• internal metadata is for orchestration only
• user-facing replies should be rewritten in normal assistant voice

Changelog evidence

The changelog already contains multiple fixes in this same family, which suggests this is an existing class of boundary bugs rather than one misconfigured local prompt:

• leaked inline reply tags stripped from completion announces
• NO_REPLY / silent token leaks suppressed
• heartbeat/internal ack summary leaks suppressed
• approval metadata sanitized
• reasoning/internal text suppression on outbound paths
• subagent/announce delivery hardening across many releases

So the likely bad boundary is:

1. background run finishes
2. runtime emits internal completion/announce payload
3. rewrite/synthesis step is supposed to convert it to normal user-facing text
4. raw payload sometimes escapes to the final delivery path

Expected behavior

For any runtime-generated completion / announce / follow-up event:

• internal metadata should never be delivered verbatim to end-user chat
• only rewritten/sanitized user-facing text should be sent
• file paths, internal session IDs, routing labels, internal wrapper blocks, and orchestration instructions should be stripped before delivery

Actual behavior

Raw internal completion/report text can appear in user chat, including execution details that clearly belong to internal orchestration rather than end-user messaging.

Suspected scope

Likely affects the shared boundary for:

• cron isolated announce deliveries
• subagent completion announces
• runtime-generated follow-up events / internal completion events

Likely not specific to:

• Telegram transport itself
• OAuth provider behavior
• one single cron prompt

Minimal repro ideas

I don’t have a fully minimized vanilla repo repro yet, but these patterns seem sufficient:

Repro A: isolated cron announce with operational text in completion

1. Create an isolated cron (payload.kind = agentTurn, delivery.mode = announce)
2. Prompt it to:
   • write a file
   • then send/return a final user-facing reminder/message
3. Let the run complete
4. Observe that sometimes the announce contains the full operational summary (file path + routing notes + final text) instead of only the final text

Repro B: subagent completion announce

1. Spawn a subagent/session that produces a completion summary containing obvious internal/reporting text
2. Let it announce back to the parent/requester
3. Observe raw completion framing or internal metadata sometimes surfacing in the main user conversation instead of a rewritten summary

Repro C: runtime-generated internal completion event

1. Trigger a background run that completes and emits a typed internal completion event
2. Ensure it routes back into a normal external conversation
3. Observe whether any internal wrapper text survives final reply synthesis

Notes

This seems especially plausible as a regression/edge-case around the shared announce/follow-up path, since many changelog items nearby mention:

• announce reliability
• duplicate suppression
• silent token filtering
• reply-tag stripping
• internal-event rendering consistency

It may be worth auditing the exact final-delivery path for typed internal completion events and ensuring there is a hard fail-closed sanitization layer before external delivery.

Requested outcome

• confirm whether this is a known regression in the completion/announce rewrite path
• identify the shared boundary where raw internal payloads can escape to user chat
• harden sanitization so runtime/internal completion payloads cannot be forwarded verbatim to external channels

If useful, I can follow up with more concrete transcript snippets/redacted examples from a real install.