openclaw - 💡(How to fix) Fix [discord] streaming.mode=progress unconditionally suppresses per-tool Discord messages even when the preview lane stays empty, leaving operators blind on fast tool calls

Symptom

In a Discord-routed OpenClaw session, when the agent runs a fast tool (e.g. ls, pwd, git status), the operator sees only the typing indicator and then the final answer — no visible per-tool messages, no live preview update. The work is invisible until terminal.

Concrete repro (local, OpenClaw 2026.5.26 + @openclaw/discord 2026.5.26 + @openclaw/codex 2026.5.26, default streaming.mode=progress and streaming.preview.toolProgress=true):

1. From Discord ask the agent to list a small directory: count the markdown files under ~/.openclaw/workspace/checklists/ and list their names
2. The channel shows typing for a second, then the final reply (9 markdown files: ...).
3. There is no per-tool message ("running: ls ...") and no live preview line showing the tool activity. Total dead air between request and reply.

Operators interpret this as "agent isn't thinking" or "session is stuck", which it isn't — the work happens but isn't surfaced.

Root cause

In channel-streaming-DG_pM5Sv.js (likely source src/channels/channel-streaming.ts):

function resolveChannelStreamingSuppressDefaultToolProgressMessages(entry, options) {
    if (options?.draftStreamActive === false || options?.previewStreamingEnabled === false) return false;
    const mode = resolveChannelPreviewStreamMode(entry, "off");
    if (mode === "off") return false;
    if (mode === "progress") return true;                  // <-- always-suppress
    if (options?.draftStreamActive === true) return true;  // <-- always-suppress
    return options?.previewToolProgressEnabled ?? resolveChannelStreamingPreviewToolProgress(entry);
}

When streaming.mode === "progress" (the default), per-tool messages are unconditionally suppressed under the assumption that they're being redirected into the preview draft lane. But the draft lane only fills when the agent runtime emits progressLine/tool-progress events DURING tool execution. For fast tool calls (sub-second ls/pwd/git status), the codex runtime returns before any progress event is emitted, so:

• per-tool messages: suppressed (by the rule above)
• preview lane: never updated (no progress events came in)
• net visible output: nothing until the final reply

The same suppression bug fires for any tool whose runtime doesn't emit progress events.

Proposed fix

Stop unconditionally suppressing per-tool messages. Honor streaming.preview.toolProgress as the explicit toggle (which is what the schema docstring already implies). Or — more aggressively — only suppress per-tool messages when there's evidence the preview lane is actually carrying the load (e.g. when at least one progressLine event has arrived for this turn).

Minimal patch (the "honor the explicit toggle" form):

 function resolveChannelStreamingSuppressDefaultToolProgressMessages(entry, options) {
     if (options?.draftStreamActive === false || options?.previewStreamingEnabled === false) return false;
     const mode = resolveChannelPreviewStreamMode(entry, "off");
     if (mode === "off") return false;
-    if (mode === "progress") return true;
-    if (options?.draftStreamActive === true) return true;
     return options?.previewToolProgressEnabled ?? resolveChannelStreamingPreviewToolProgress(entry);
 }

A more aggressive form is to always return false after the early safety checks — in practice the preview lane stays empty for many tool calls and operators always want per-tool visibility:

 function resolveChannelStreamingSuppressDefaultToolProgressMessages(entry, options) {
     if (options?.draftStreamActive === false || options?.previewStreamingEnabled === false) return false;
     const mode = resolveChannelPreviewStreamMode(entry, "off");
     if (mode === "off") return false;
-    if (mode === "progress") return true;
-    if (options?.draftStreamActive === true) return true;
-    return options?.previewToolProgressEnabled ?? resolveChannelStreamingPreviewToolProgress(entry);
+    return false;
 }

The "honor the explicit toggle" form is probably the right shape upstream; operators who want quiet messages can set streaming.preview.toolProgress=false.

Side-effect surface

• Operators with streaming.preview.toolProgress=true (the current default) will now see per-tool messages again. This matches the pre-2026-05-12 behavior — the "tool call show work" experience that disappeared in the upgrade.
• Operators who prefer the preview-only experience can set streaming.preview.toolProgress=false to silence per-tool messages and rely on the preview lane (when their runtime actually emits progress events).
• If both are visible (per-tool messages AND preview lane), the experience is redundant but informative. Worth ergonomic polish in a follow-up — e.g. only emit per-tool messages if the preview hasn't picked up the tool within N ms.

Companion issues

• #87665 — parent task notifyPolicy default for Discord-origin (also fixed locally).
• #87666 — codex native subagent visibility.

Together these three fixes restore the pre-2026-05-12 Discord visibility experience: parent state changes, codex subagent activity, and per-tool messages all surfacing to the channel.

Workaround until merged

Local content-anchored patch to channel-streaming-DG_pM5Sv.js applying the diff above (or the equivalent in source).

Environment: macOS, OpenClaw 2026.5.26, @openclaw/discord 2026.5.26, @openclaw/codex 2026.5.26, node 22.