Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In Control UI / WebChat, a failed internal tool call from the assistant can be rendered as a prominent red error banner in the normal chat timeline, even when the assistant already produced a clean final reply. In the reproduced case, a hidden shell search command returned exit code 1 only because it found no matches, but the UI surfaced that internal tool activity as if it were the user-facing error.

Steps to reproduce

1. Open Control UI / WebChat on a recent OpenClaw build.
2. Use a Codex-backed chat session where the assistant performs internal tool calls during analysis.
3. Trigger a turn where one hidden tool call exits non-zero without representing the final user-visible outcome (for example, a shell search command that returns exit code 1 for no matches).
4. Let the assistant finish the turn and send a normal final reply.
5. Observe the same chat in Control UI: the timeline shows a red failure banner containing the internal tool command text instead of keeping that detail hidden or debug-only.

Expected behavior

Internal assistant tool calls and tool results should stay hidden from the normal chat timeline by default, or at minimum remain collapsed behind an explicit debug/activity view.

A non-zero internal tool exit should not be rendered as the primary visible chat error unless the assistant explicitly surfaces it as the user-facing outcome for the turn.

Actual behavior

The chat view rendered a red error banner containing the internal shell command text from a hidden tool call. The same turn also had a successful final assistant reply visible below it.

The stored session transcript for that turn showed an assistant toolCall followed immediately by a toolResult with isError: true and { "status": "failed", "exitCode": 1 }. The non-zero exit was caused by a no-match search command, not by the final user-visible outcome of the turn.

OpenClaw version

2026.5.28 (e932160)

Operating system

Ubuntu 26.04 LTS

Install method

pnpm

Model

gpt-5.4 (observed for the reproduced turn; environment may also route some turns to gpt-5.5)

Provider / routing chain

openai-codex

Additional provider/model setup details

Observed in a Codex-backed main chat session in Control UI / WebChat. No special provider routing was required beyond the normal Codex runtime for that agent.

Logs, screenshots, and evidence

- Screenshot evidence: the visible chat shows a red banner containing the exact internal command text while the assistant's final prose answer is also present in the same turn.
- Transcript evidence: the same turn stored an assistant `toolCall` for a shell command followed by `toolResult isError: true` with `{ "status": "failed", "exitCode": 1, "durationMs": 0 }`.
- The failing command was an internal log search that returned exit code 1 because no matches were found.
- The visible banner text matched the hidden tool-call command text exactly.
- This appears related to existing Control UI tool-rendering issues such as #83494 and #81630, but this repro is specifically about failed hidden tool activity being surfaced as a user-facing error banner after a completed reply.

Impact and severity

Medium. It leaks internal tool activity into the normal user-visible chat surface, makes routine non-fatal tool exits look like product/runtime failures, and can mislead users during debugging because the banner competes with or overrides the real assistant outcome of the turn.

Additional information

The reproduced failure did not require an actual gateway/runtime fault. The surfaced red banner came from internal tool activity recorded in the session transcript, not from a fresh backend session-resolution failure. A likely fix direction is to keep hidden/internal tool activity out of the normal chat lane, or at least gate failed tool-result banners behind an explicit debug/activity toggle.