openclaw - 💡(How to fix) Fix Bug: Slack live draft replaced by tool failure status during streaming

Summary

In Slack, an in-flight assistant draft can be replaced by a tool failure/status message when a tool call fails during a streamed reply. This happened even though Slack preview tool progress is disabled in config.

Observed behavior

While the assistant was composing/streaming a Slack reply, it called apply_patch. The tool failed with a workspace-boundary error because the target path was outside the patch tool's allowed root. Instead of leaving the assistant draft intact, the Slack-visible message was replaced by a compact tool-status line:

:warning: :adhesive_bandage: Apply Patch failed

The assistant then continued and used a different file-editing tool successfully, so the underlying tool failure was expected/recoverable. The issue is that the tool status appeared to overwrite the Slack draft.

Expected behavior

When Slack streaming is active and tool progress is disabled:

• Tool failure/progress should not replace the assistant's in-flight draft.
• A tool failure should remain internal, become a reaction/status card, or be shown on a separate progress surface.
• The assistant draft should remain intact until the final assistant reply is delivered.

Actual behavior

The live Slack draft was visually replaced by the failed tool status text.

Relevant config, sanitized

Current Slack streaming config at the time of the incident:

{
  "mode": "partial",
  "chunkMode": "length",
  "block": {
    "enabled": false
  },
  "nativeTransport": false,
  "preview": {
    "toolProgress": false
  }
}

No tokens, channel IDs, user IDs, or message content are included here.

Sanitized repro shape

1. Use Slack channel delivery with streaming enabled in partial mode.
2. Set channels.slack.streaming.preview.toolProgress=false.
3. Begin producing an assistant reply in Slack.
4. During the same turn, run a tool that fails after the draft exists. In this case it was apply_patch failing because the target file path was outside its allowed root.
5. Observe Slack: the assistant draft can be replaced by a compact tool failure/status line such as :warning: :adhesive_bandage: Apply Patch failed.

Why this looks like an OpenClaw bug rather than local config

The obvious local mitigation, channels.slack.streaming.preview.toolProgress=false, was already set. That makes the Slack-visible tool failure look like progress/status reconciliation leaking into the assistant draft lane.

A local investigation found relevant code/schema areas:

• /opt/homebrew/lib/node_modules/openclaw/dist/io-E69J4lLI.js
  • Slack streaming schema includes streaming.preview.toolProgress and streaming.progress.toolProgress.
  • Local grep hits included these schema/doc entries around toolProgress and streaming.* keys.
• /opt/homebrew/lib/node_modules/openclaw/dist/agent-runner.runtime-DQsCsHUA.js
  • Agent events route tool and patch events through callbacks, including evt.stream === "tool" and evt.stream === "patch" / onPatchSummary.
• Delivery appears to share message/hook reconciliation paths for outgoing updates.

This is not a full source-level root cause, but it matches the observed symptom: a shared Slack draft/progress surface appears to be reused or reconciled too aggressively.

Related issue

This may be related to, but is not identical to, #25592 (Text between tool calls leaks to messaging channels). The symptom here is specifically a tool failure/status line overwriting a Slack live draft despite tool progress being disabled.

Environment

• OpenClaw version: 2026.5.7 (eeef486)
• Host OS: macOS / Darwin arm64
• Channel: Slack
• Slack streaming mode: partial
• nativeTransport: false
• preview.toolProgress: false

Suggested fix direction

Ensure tool/progress/failure status updates cannot edit or replace the assistant draft message when tool progress is disabled. If a progress surface is needed, it should use a separate message/status/reaction path from streamed assistant content, or be gated by the relevant toolProgress config consistently.