openclaw - 💡(How to fix) Fix [Bug]: Telegram DM startup/runtime context and async follow-up scaffolding can leak into user-visible messages [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Fresh Telegram DM sessions and some async follow-up turns can surface internal runtime/startup context as user-visible assistant messages instead of keeping it internal.

Steps to reproduce

1. Use OpenClaw with Telegram enabled and a DM session route.
2. Start or reset a Telegram DM session (observed on /new/fresh-session style starts).
3. In affected cases, inspect the resulting session transcript and the user-visible DM output.
4. Separately, trigger an async follow-up/completion path that spawns a new turn/session.
5. Observe that internal runtime text or completion-relay scaffolding can leak into user-visible assistant output.

Expected behavior

• Runtime-injected startup/session context (for example openclaw.runtime-context) should remain internal and never be emitted as user-visible assistant text.
• Async completion follow-up sessions should only produce a user-facing reply when a real completion payload is present.
• Fresh DM startup/session bootstrapping should not expose raw metadata, session summaries, or helper scaffolding to the user.

Actual behavior

Two related leak paths were observed:

1. Fresh Telegram DM session startup path

   • Session transcripts contain runtime-injected custom_message blocks with customType: "openclaw.runtime-context".
   • Those blocks include raw chat metadata and, on new-session startup, quoted daily-memory/session-summary content.
   • This is consistent with the family of bugs where runtime context escapes into user-visible output.

2. Async completion follow-up path

   • A new session/turn is started with the injected prompt: An async command you ran earlier has completed. The result is shown in the system messages above. Please relay the command output to the user in a helpful way...
   • In failing cases, the actual completion payload is not present.
   • The model then probes process list, finds no relevant session, and emits bogus fallback text to the user.

Observed leaked/user-visible examples include text shaped like:

• OpenClaw sees the immediately preceding message as a Telegram direct message from you ...
• raw chat_id, message_id, sender metadata, and timestamps
• tool/provider dumps that should not have been delivered to the user

OpenClaw version

2026.4.26

Operating system

Ubuntu Linux

Install method

npm / packaged OpenClaw install

Model

Observed with OpenAI Codex (gpt-5.2 and gpt-5.4 session transcripts present)

Provider / routing chain

OpenClaw -> Telegram

Additional provider/model setup details

Observed in Telegram direct-message sessions for sender 8614088321, while related topic/group routing remained distinct.

Logs, screenshots, and evidence

Evidence from local session transcripts showed:

• Telegram DM session key: agent:main:telegram:direct:8614088321

• Fresh-session transcript containing runtime-injected startup context:

  • session file: 2d01f984-c08a-4aa3-bee4-3f5d214bf725.jsonl
  • included custom_message with customType: "openclaw.runtime-context"
  • content included startup instructions plus quoted daily-memory/session-summary blocks

• Separate async-relay transcripts containing injected completion scaffolding without payload:

  • prompt begins with: An async command you ran earlier has completed. The result is shown in the system messages above...
  • examples found in session transcripts such as: 7e99520d-2dbc-4f17-b0bf-448644990eb0.jsonl 81bc813f-a1eb-492d-b41f-40380d177960.jsonl 749412d6-3188-4de9-8ae7-d9d44b8840b2.jsonl

Relevant prior related report:

• #73906 — runtime context message leaked into assistant public reply and persisted downstream

This new report is narrower on Telegram DM startup/runtime-context injection plus async follow-up sessions that lack payload but still speak.

Impact and severity

Affected users: Telegram/OpenClaw users with DM sessions and/or async follow-up paths Severity: Annoying to privacy-sensitive / workflow-breaking Frequency: Repeated Consequence:

• internal/runtime text can be exposed to end users
• DM sessions can be polluted with startup/internal scaffolding
• bogus async follow-up replies can appear even when no real result exists

Additional information

Based on transcript inspection, the likely root-cause area is runtime/session orchestration, not Telegram topic routing itself.

Likely fix directions:

1. Ensure openclaw.runtime-context and similar startup injections are never eligible for user-visible relay/output.
2. Ensure async completion follow-up sessions only fire when a real completion payload is attached.
3. Treat startup helper/session boot messages as strictly internal context, especially on fresh DM sessions.

This may overlap with #73906, but that report was closed quickly and did not appear to cover the repeated Telegram DM startup/session behavior plus the payload-less async follow-up path together.