Summary

In a Telegram direct chat, OpenClaw is repeatedly delivering raw internal tool/command failure messages to the user after automated agent runs. This has become a daily reliability and UX problem: the user sees low-level agent/tool failure notices instead of a clean agent-owned summary or a silent internal diagnostic record.

Environment

• OpenClaw version: 2026.6.1 (2e08f0f)
• Channel: Telegram direct chat
• Runtime: OpenClaw-managed agent using Codex harness
• Pattern: scheduled/automated operational workflows that run shell/CLI tools during the agent turn

Observed behavior

Examples of user-visible messages delivered directly into Telegram:

⚠️ 🛠️ jq -r '.events[] | select(.eventType=="fromGmail" or (.summ…ity,description} | @json' /tmp/all-agenda-2026-06-11-7d.json (agent) failed

⚠️ 🛠️ jq '.[] | select(.date=="2026-06-15")' frentes/gualapack/projetos/briefings-diarios/config/feriados-brasil-2026.json (agent) failed

There was also a noisy automated failure notice for a cron/model capacity problem:

Cron job "flush-inteligencia-gualapack" failed 1 times
Cause: overloaded
Last error: FailoverError: Selected model is at capacity. Please try a different model.

Expected behavior

Raw tool failures should not be delivered as standalone user-facing chat messages by default.

Preferred behavior:

1. Capture the failure internally in logs/diagnostics/session state.
2. Let the agent decide whether and how to mention it in the final visible response.
3. If OpenClaw must surface it, use a concise structured summary that avoids raw commands, local paths, partial payloads, and machine-only details.
4. For cron/automated runs, only notify the user when the failure is actionable or repeated beyond a configurable threshold.

Impact

• The user receives confusing technical noise in a personal chat.
• It exposes raw commands and local paths unnecessarily.
• It makes otherwise successful daily automation look broken even when the main briefing/journal was delivered.
• It erodes trust because the same class of failure is appearing repeatedly.

Suggested fix

Add a delivery guard around tool/runtime failure notifications for channel surfaces:

• Default: keep raw tool failure details internal.
• Provide an agent-visible diagnostic event so the agent can summarize naturally.
• Add a channel-safe fallback message only if the run cannot complete and user action is required.
• Consider a config flag for "developer verbose failures" versus "human chat safe failures".

Diagnostics

A local OpenClaw diagnostics bundle was generated after the latest occurrence and can be provided privately if useful. I am not attaching it publicly because diagnostics may still contain operational host/runtime metadata.