openclaw - 💡(How to fix) Fix Discord outbound leaks 🛠️ tool-progress lines when agent is in Barnacling state (stripper bypassed) [1 pull requests]

Summary

Internal tool-call narration lines (e.g. 🛠️ show ~/.openclaw/workspace-system-design/working.md → print text) are reaching the Discord channel for the nails-cloud-system-design agent. Discord normally strips these via stripDiscordInternalTraceLines + stripDiscordInternalRuntimeScaffolding — so this is a regression on the Discord side, not the same bug as #87315 (which covers the WhatsApp adapter lacking the stripper entirely).

Versions

• openclaw runtime visible to dev-manager: see Runtime block in dev-manager system prompt
• Channel: Discord #dev-storm (guild 1467195892674068553, channel 1467203509261959343)
• Affected agent account: nails-cloud-system-design (Discord id 1467613063787315314)

Evidence (UTC)

Three messages in #dev-storm matching the leaked-tool-trace shape, each prefixed with Barnacling (OpenClaw busy indicator):

1. nails-cloud-dev ~2026-05-30T13:30Z — 🛠️ show working.md -> show first 60 lines → print text → list files in working.md -> show first 3 lines
2. nails-cloud-system-design ~2026-05-30T13:31Z — 🛠️ show ~/.openclaw/workspace-system-design/working.md → print text
3. nails-cloud-system-design ~2026-05-30T13:35Z (msg id 1510275344337338378) — 🛠️ show ~/.openclaw/workspace-system-design/working.md -> show first 60 lines

Also one peer message of shape 🧾 Session History: session current, limit 20 (history-tool progress shape, similar leak class).

Both agents (nails-cloud-dev, nails-cloud-system-design) confirmed via in-channel reply that their agent inbound never received these as user input — i.e. these are NOT injection attempts being processed by the LLM. They're emitted by the runtime tool-progress display path and leaking past the Discord stripper to the channel.

Differentiation from #87315

• #87315: WhatsApp adapter has no sanitizeText, so 🛠️/🩹 lines pass through. Fix scope = WhatsApp adapter.
• This issue: Discord adapter HAS stripDiscordInternalTraceLines + stripDiscordInternalRuntimeScaffolding, but at least one code path (likely the Barnacling-prefixed busy-indicator update or a tool-progress-reaction-to-message fallback) bypasses or precedes those strippers. Fix scope = Discord outbound path / busy-indicator emit path.

Hypothesis

The Barnacling prefix is the agent-busy indicator. If the indicator update is sent via a code path that builds the message body from summarizeExecCommand/classifyWorkspacePath output but skips stripDiscordInternalTraceLines (e.g. an edit-in-place to an existing indicator message, or a fallback when reaction-based progress fails), that would explain the 🛠️ shape leaking only when the agent is in Barnacling state.

Worth grepping the Discord outbound path for any sendMessage/editMessage callsite that takes a pre-formatted tool-trace string without routing through the stripper.

Impact

• Channel noise (every tool-progress event leaks as a real Discord message → 1 channel post per tool call when an agent is busy).
• Initial false-positive prompt-injection alarm — operator saw the 🛠️ show <file> → print text shape and treated it as exfil-shaped adversarial input until both agents confirmed they didn't author the messages.
• Cross-agent confusion: the leaked-message account-attribution suggests Agent B is asking Agent A to dump files, when really the runtime is emitting Agent B's own tool-progress text into the channel.

Repro hint

Trigger any tool call on a Discord-channel-bound agent that's in the Barnacling busy state and watch the channel for the 🛠️ shape escaping the stripper. Likely correlates with a specific tool-progress emit path (busy-indicator edit vs reaction).

Suggested next steps

1. Confirm reproduction in a clean test channel.
2. Locate the Discord outbound path that bypasses stripDiscordInternalTraceLines for Barnacling-state messages.
3. Either route that path through the existing stripper or suppress the busy-indicator-progress-as-message fallback for Discord targets.