Summary

Reply delivery can surface internal scaffolding to users when assistant-visible text includes:

• the current-message priority prompt (Current message priority: ... [Current message - respond to this])
• a bare (no output) placeholder

This showed up in a Telegram/system flow while testing reply delivery after an OpenClaw update.

Expected behaviour

User-facing reply normalization/sanitization should drop these internal-only strings before delivery. If nothing user-visible remains, the reply should be skipped.

Local patch prepared

I prepared a local patch/commit with regression tests:

9538ed3b fix: suppress leaked reply scaffolding

Patch scope:

• sanitizeUserFacingText(...) strips leaked current-message-priority prompt wrappers while preserving real reply text
• sanitizeUserFacingText(...) suppresses bare (no output) placeholders
• normalizeReplyPayload(...) treats bare (no output) as skipped with reason empty-tool-output
• regression coverage added for sanitizer and normalizer paths

Verification run locally

• vitest run src/agents/pi-embedded-helpers.sanitizeuserfacingtext.test.ts src/auto-reply/reply/reply-utils.test.ts → 164 tests passed
• node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental false → passed
• git diff --check → clean

PR blocker

I could not open a PR directly yet because this checkout appears to have been based on a newer packaged/source tree than my fork's current default branch. Direct push to upstream is denied, and pushing the branch to my fork failed with a missing object error. Applying the patch onto the fork default branch also failed because the relevant src/... files are not present there.

So this issue captures the bug, expected fix, and local verification. I can attach/paste the exact patch if useful.