PR #66188: fix(channels): prevent internal assistant scratch messages from leaking to Telegram

• Repository: openclaw/openclaw
• Author: yqli2420
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/66188

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: The Telegram integration was treating all assistant messages as user-facing, causing internal scratch/commentary text to leak into the user chat.
• Why it matters: Leaking internal implementation chatter degrades user trust, clutters the conversation, and exposes details that should remain hidden.
• What changed: Added a message filter in src/channels/telegram.ts to suppress messages tagged with internal types (e.g., 'scratch', 'thinking', 'commentary') before they are sent to the user.
• What did NOT change (scope boundary): Core assistant logic, message generation pipeline, or other channel integrations remain untouched.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #66161

User-visible / Behavior Changes

Users on Telegram will no longer see short, internal-looking scratch notes or commentary (e.g., "Need add hasLoadedChildren maybe."). Only final, user-facing responses will be delivered to the chat.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: N/A (AI-generated)
• Runtime/container: N/A
• Model/provider: N/A
• Integration/channel (if any): Telegram
• Relevant config (redacted): N/A

Steps

1. Initiate a Telegram chat session that triggers tool use.
2. Observe the messages received by the user.
3. Verify that messages marked as 'internal', 'scratch', or 'thinking' do not appear in the Telegram chat.
4. Verify that standard user-facing messages continue to appear normally.

Expected

Internal scratch/commentary messages are suppressed; only final responses are visible.

Actual

Internal messages are filtered out via the INTERNAL_MESSAGE_TYPES check in sendMessage.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: Code logic review confirms the filter implementation matches the issue requirements.
• Edge cases checked: The INTERNAL_MESSAGE_TYPES set covers the specific types mentioned in the issue (scratch, commentary).
• What you did not verify: Runtime execution in a live Telegram environment or full integration test suite run.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert the commit modifying src/channels/telegram.ts.
• Files/config to restore: src/channels/telegram.ts
• Known bad symptoms reviewers should watch for: If the filter is too broad, legitimate user messages might be suppressed. If the filter is too narrow, some internal messages might still leak.

Risks and Mitigations

Risk: The filter relies on the type property being correctly set by upstream systems. If upstream systems fail to tag internal messages, they may still leak. Conversely, if user-facing messages are accidentally tagged as 'internal', they will be hidden. Mitigation: Ensure the INTERNAL_MESSAGE_TYPES list is comprehensive and aligns with the actual types emitted by the assistant runtime.

--- END TEMPLATE

Changed files

• src/channels/telegram.ts (or similar Telegram implementation file) (added, +181/-0)