openclaw - 💡(How to fix) Fix [Bug]: Tool-error final can include unbounded raw output and flood channels

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In one observed Feishu DM run, OpenClaw surfaced a tool-error final as intended, but the error detail included unbounded raw failed rg output; the channel split that oversized payload into 252 Feishu card messages.

Steps to reproduce

1. Run OpenClaw 2026.5.18 with a Feishu/Lark channel plugin in static card mode.
2. In a chat-backed Codex/OpenClaw session, trigger a broad local search that scans OpenClaw session history, for example an rg -n command over $HOME/.openclaw and a workspace memory/journal directory with several broad terms and without --max-count or file exclusions.
3. Let the search produce a large amount of stdout and then fail or get interrupted by the runner/tool layer.
4. Observe channel delivery for the user-visible tool-error final.

Expected behavior

Tool failure visibility is useful and expected, but user-visible error detail should be bounded:

• user-visible tool error fallback should be concise, capped, and summarized;
• raw tool stdout/stderr should not be inserted wholesale into user-visible error text;
• model-visible, trajectory-visible, and channel-visible tool-result caps should not diverge enough for a channel to receive hundreds of messages from one failed tool result.

Actual behavior

Observed on 2026-05-28:

• A normal final answer was delivered at 13:38:17 local time.
• At 13:38:18, the same inbound message received a user-visible tool-error final whose preview started with ⚠️ 🛠️ search "<redacted broad search terms>" ....
• The Feishu/Lark channel logged deliver: sending card chunks (count=252, ...).
• Dispatch completed at 13:41:54 after sending the chunked payload.

The failed bash/rg tool result in the trajectory had:

status: failed
isError: true
exitCode: -1
durationMs: 29503
outputChars in trajectory: 20001

The persisted model-visible toolResult for the same failed search was capped to 12018 characters and ended with ...(truncated).... The channel-visible payload was much larger, since 252 static-card chunks at the default 4000-character chunk limit implies roughly 1,000,000 characters of Feishu-visible text.

OpenClaw version

2026.5.18

Operating system

Ubuntu 22.04

Install method

npm global, launched as a user systemd gateway service

Model

NOT_ENOUGH_INFO

Provider / routing chain

OpenClaw gateway -> Codex app-server / openai-codex auth profile. Exact model was not captured in the available evidence.

Additional provider/model setup details

Observed with @larksuite/openclaw-lark 2026.5.7 in Feishu static card mode. The core issue is that a raw failed tool output/error payload crossed into user-visible final delivery after a successful final answer; the channel flood is the most visible consequence.

Logs, screenshots, and evidence

Redacted timeline from gateway logs:

13:38:17.568 deliver called (... kind=final)                # normal final answer
13:38:17.570 deliver: sending text chunks (count=1)
13:38:17.669 message processed ... outcome=completed
13:38:18.481 deliver called (textPreview=⚠️ 🛠️ search "<redacted broad search terms>" ..., kind=final)
13:38:18.690 deliver: sending card chunks (count=252)
13:41:54.512 dispatch complete (replies=2, elapsed=415714ms)

Redacted failed search command shape:

rg -n "<redacted broad search terms>|300|winner|battle" "$HOME/.openclaw" "$WORKSPACE/.claworld" 2>/dev/null

Related but not identical existing issues:

• #25592 tracks intermediate text leaking to channels generally.
• #70797 tracks tool-call payload leakage during background exec/process flows.

This issue is specifically about user-visible tool-error detail being insufficiently capped/summarized, with model-visible and channel-visible truncation diverging severely.

Impact and severity

Affected: Feishu/Lark users on a chat-backed OpenClaw gateway; possibly any channel that accepts a large final/error payload without its own hard cap.

Severity: High. One failed broad search generated hundreds of user-visible Feishu messages from a single turn.

Frequency: One observed incident with direct log/session evidence. Broader frequency is NOT_ENOUGH_INFO.

Consequence: User-visible message flood, chat usability disruption, and possible exposure of raw historical session/search output that should remain internal or summarized.

Additional information

OpenClaw should likely enforce this before channel dispatch, not only in individual channels:

• keep raw tool stdout/stderr from being copied wholesale into user-visible tool-error final payloads;
• cap lastToolError.error / user-visible tool error detail independently of transcript/model caps;
• ensure channel-visible payload size cannot exceed the bounded model-visible/trajectory-visible representation for the same failed tool output.