Summary

In OpenClaw 2026.5.12, a message.send tool call can successfully post to Slack but still return to the model as isError: true with:

Tool output unavailable due to post-processing error.

This can make a successful user-visible Slack delivery look like a failed send.

Environment

• OpenClaw: 2026.5.12 (f066dd2)
• Gateway: macOS LaunchAgent
• Requester channel: Slack thread

Observed

In one inspected run:

• Run: <run-id>
• Slack channel: <slack-channel-id>
• Slack thread: <slack-thread-ts>
• Child session: <child-session-jsonl>

Transcript sequence:

• The first message.send had channel/threadId but no explicit target; it correctly failed with:

Explicit message target required for this run. Provide target/targets (and channel when needed).

• The retry included target="<slack-channel-id>", channel="<slack-channel-id>", threadId="<slack-thread-ts>", and the completion text.
• That retry returned isError: true with:

Tool output unavailable due to post-processing error.

• A subsequent message.read of the same Slack thread returned ok: true and showed the exact reply posted at Slack:

ts="<slack-message-ts>", thread_ts="<slack-thread-ts>"

The observed timestamps line up with this ordering: the send call happened first, the Slack-visible reply was created next, and the failed tool result came after that.

Likely Cause

The generic error appears to be produced in:

• dist/tool-result-middleware-ecm3p4oK.js
• source label: src/agents/harness/tool-result-middleware.ts

buildMiddlewareFailureResult() returns content text Tool output unavailable due to post-processing error. with details: {status: "error", middlewareError: true}.

For Codex dynamic tools, tool.execute(...) runs first, then middlewareRunner.applyToolResultMiddleware(...) runs on the raw result. For message.send, the Slack side effect can happen inside tool.execute(...). If tool-result middleware throws or rejects the candidate result after that, OpenClaw can discard the successful raw result and substitute the generic middleware failure result. The Codex bridge then exposes the tool response as isError: true, even though Slack already received the message.

Expected

For successful non-idempotent side-effect tools such as message.send, a post-processing failure should not make the public tool result indistinguishable from delivery failure.

If the raw execution result contains successful delivery identifiers, return a successful minimal result preserving fields such as messageId, channelId, and threadId, and surface middleware failure only as a warning/diagnostic.

Proposed Fix

• Preserve side-effect success across post-processing failures for message.send.
• If preserving the original details is unsafe because middleware validation fails, strip or normalize details rather than replacing the whole result with status:"error".
• Add regression coverage for: successful Slack/message send raw result + forced tool-result middleware exception/invalid candidate result. The final tool response should remain success and include delivery identifiers.