Summary

When a cron job's agent turn ends with status: error and no final assistant message, the cron-delivery layer synthesizes a fallback summary by paraphrasing the failing bash tool invocation into a stepwise English list (e.g. create folder X → run then set → run [ → run jq → run true) fi …). The synthesized string is then announced verbatim to the configured channel (Discord, in my case). The result reads as gibberish even though the underlying failure (e.g., a webhook returning HTTP 500) is legitimate and worth surfacing.

Repro

1. Configure a cron job that delivers via delivery.mode: "announce" (Discord).
2. Have its prompt invoke a bash tool call with a multi-line script that includes shell control-flow keywords (if, then, fi, set, [, jq, etc.).
3. Make the script exit non-zero (e.g., the inner command hits a real 5xx) without a set +e; …; exit 0 safety wrap, and have the model end the turn without producing a final assistant message.
4. Observe the Discord notification.

Observed

Sample Discord messages from one job (8fbdb11f-…, model gpt-5.5 via openai-codex):

• 2026-05-20 17:01 PT — ⚠️ 🛠️ `show > → run f, → run your (agent)` failed
• 2026-05-20 20:01 PT — ⚠️ 🛠️ `create folder ~/.openclaw/workspace/.tmp → run f, → run s official → run your (agent)` failed
• 2026-05-21 11:00 PT — ⚠️ 🛠️ `create folder ~/.openclaw/workspace/.tmp → run then set → run true set → run [ → run then -> run jq → run true) fi → run python3 scripts/birdweather.py -> run sed transform (+2 steps) → run true) cat (agent)` failed
• 2026-05-21 22:00 PT (different job) — ⚠️ 🛠️ `run for sub → run do printf → fetch https://www.reddit.com/r/\$sub/hot.json?limit=25 -> run jq → run done (agent)` failed

Each shell keyword (then, set, [, fi, jq, true) in the original bash gets emitted as its own → run X step. The leading mkdir -p .tmp correctly paraphrases to create folder ~/.openclaw/workspace/.tmp, but everything after that is just whitespace-tokenized shell keywords.

The corresponding session trajectories (agents/main/sessions/<sid>.trajectory.jsonl) show 2–5 normal tool calls, no assistant.message event, and the turn ending without a wrap-up.

Expected

When the failing tool is bash/shell/equivalent, skip the natural-language paraphraser and emit something like:

Agent turn failed: bash exited <code> with no final message. Last command: <cmd[:120]>…

The paraphraser may still be useful for higher-level tools where verbs map cleanly (file_write, web_fetch, etc.). For raw shell it produces no value and actively misleads.

Why this matters

Two effects compound:

1. The actual failure signal (a real cron tick that didn't finish its work) gets buried — users learn to tune out the gibberish and miss real outages.
2. The notification looks like the agent has gone off the rails, which provokes follow-up debugging in the wrong direction.

Workaround

Harden the cron job's prompt so the agent (a) wraps inner failure-prone bash with set +e; …; exit 0 so the turn-level status stays ok, and (b) always emits a final assistant message even on internal failure. That sidesteps the paraphraser entirely. Doing this in my own job's prompt eliminates the garbled DMs locally, but the underlying paraphraser bug remains for anyone who hasn't hardened their prompts.

Environment

• openclaw 2026.5.26
• macOS 25.5.0 (darwin)
• Codex provider, model gpt-5.5

Issue drafted with assistance from Claude (Anthropic) per CONTRIBUTING.md AI-disclosure guidance; repro evidence and proposed fix are from local trajectory data.