[Bug]: Feishu direct repeatedly leaks internal ... (agent) failed / generic failure banners to users, including malformed tool summaries and false failures after successful runs

Summary

Over the period 2026-05-20 through 2026-06-01 in a Feishu direct conversation, OpenClaw repeatedly surfaced user-visible failure banners that were either:

• raw internal tool-summary leakage
• malformed / truncated command labels
• generic external-run fallback messages
• or outright false-failure banners even though the underlying task later succeeded

From the user's perspective, these all look like the same product failure:

"Why is the agent always echoing weird failed messages at me?"

This appears broader than a single command-specific bug such as grep exit(1) or one isolated session-stall issue. It looks like the front-end failure translation / suppression path is inconsistent across several failure families.

Environment

• OpenClaw: 2026.5.28
• OS: macOS Darwin 25.5.0 arm64
• Node: v26.0.0
• Channel: Feishu direct
• Primary runtime seen in the incidents: openai-codex/gpt-5.4

What the user actually saw

Representative user-visible strings from this period included:

⚠️ 🛠️ search "|/.openclaw|workspace/" in /private/tmp/openclaw-gh-hEDcwh (agent) failed
⚠️ 🛠️ run python inline script (heredoc) (agent) failed
⚠️ 🛠️ run npm outdated (agent) failed
⚠️ 🛠️ run python3 inline script (heredoc) (agent) failed
⚠️ 🛠️ list files in ~/Downloads/...docx (agent) failed
⚠️ 🛠️ jq -r 'to_entries[] | select(...) | [.key,.value] | @tsv' ... (agent) failed
⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.
⚠️ Codex stopped before confirming the turn was complete. Some work may already have been performed; verify the current state before retrying.
⚠️ run openclaw (agent) failed

Why this report is broader than one existing issue

Existing reports cover parts of the family:

• #87610 — Telegram shows internal ⚠️ 🛠️ ... failed for normal grep exit(1)
• #88312 — Codex turn-completion stall returns Codex stopped before confirming...
• #89245 — Feishu direct can become unusable after /reset or /new and fall back to generic Something went wrong...

This issue is about the aggregate UX failure in Feishu direct:

• multiple internal failure forms are escaping user-facing suppression
• the same user sees them across many unrelated tasks
• some are real runtime failures, but some are only tool-label summaries or even false negatives after a successful run
• the product currently does not reliably translate them into a stable user-facing status model

Incident timeline

1. 2026-05-20: raw search failure leaked

User reported seeing:

search "|/.openclaw|workspace/" in /private/tmp/openclaw-gh-hEDcwh (agent) failed

This was just a failed search pattern / regex usage issue, but the internal task label was surfaced directly to the user.

2. 2026-05-21: heredoc/python failure summary looked like nonsense

User repeatedly saw:

run python inline script (heredoc) (agent) failed

In at least one related case, the true underlying stderr was:

ModuleNotFoundError: No module named 'requests'

So the displayed banner was not the real root cause. In nearby variants, the label itself was malformed/truncated (for example run re.s) ... failed style summaries).

3. 2026-05-22 / 2026-05-26: internal command-chain failures leaked again

Observed/reported forms included:

run npm outdated (agent) failed
run python3 inline script (heredoc) (agent) failed
run python3 ~/.openclaw/venvs/weasyprint → run pip install → run pip install (agent) failed

Again, these are low-level execution labels, not user-ready explanations.

4. 2026-05-27: file-task failure banner + generic failure fallback

The user explicitly reported seeing both:

⚠️ 🛠️ list files in ~/Downloads/20260526-2026年上半年工作总结和下半年工作计划/公共应用组件团队2026上半年年工作总结和下半年工作计划.docx (agent) failed
⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

In that case the task artifact later existed, but the user-facing flow did not clearly communicate:

• whether the work actually failed
• whether a file was already generated
• whether retry was needed

5. 2026-06-01 morning: false failure after successful run

User saw:

run openclaw (agent) failed

But local forensics showed the answer had actually completed successfully; the visible failure came from an internal polling mismatch while resuming a running command session.

This is especially bad UX because it teaches the user to distrust even successful completions.

6. 2026-06-01 afternoon/evening: repeated turn-completion stall banners

User repeatedly saw:

Codex stopped before confirming the turn was complete. Some work may already have been performed; verify the current state before retrying.

This is at least more informative than raw ... (agent) failed, but it still surfaced repeatedly in a way that looked like the agent was flapping, even though some work had already happened. This overlaps with #88312.

7. 2026-06-01 evening: frontstage debugging leaked a raw jq failure banner

User saw another internal tool banner:

⚠️ 🛠️ jq -r 'to_entries[] | select(.key|test("feishu:direct:...")) | [.key,.value] | @tsv' ... (agent) failed

This came from frontstage debugging of session state. The command itself was exploratory / diagnostic and should never have become user-visible product copy.

8. 2026-06-01 evening: broken session recovery degraded to generic fallback

After a real upstream failure and subsequent /reset / /new, the user later received:

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

That case is tracked more specifically in #89245, but it belongs in the same overall UX family.

Problem statement

These incidents suggest OpenClaw currently has multiple unsynchronized user-facing error channels:

1. raw tool-status banner leakage
2. fallback reply text for embedded-run failures
3. model/runtime-specific warning copy
4. command/task-label summarization that can truncate or garble the label

The result is that a normal user on Feishu direct can see a stream of:

• low-level shell snippets
• malformed heredoc labels
• runtime warnings
• generic "Something went wrong" messages

without a stable explanation of:

• did the task actually fail?
• was any work already completed?
• is there an output artifact?
• should the user retry, wait, or ignore the banner?

Expected behavior

For end-user conversations, OpenClaw should strongly prefer:

1. suppress raw internal tool banners by default
2. translate failures into a consistent user-facing status model
3. if work partially succeeded, say so explicitly
4. never show malformed command summaries like truncated heredoc / regex / jq labels
5. avoid "failure" banners on success-path turns where the final answer already exists

Actual behavior

The same Feishu user repeatedly receives a mixture of:

• ⚠️ 🛠️ ... (agent) failed
• generic ⚠️ Something went wrong...
• runtime stall copy
• and command labels that look like shell garbage

This creates high UX noise and low trust, even in cases where the task eventually succeeded.

Suggested fixes

1. Add a strict suppression layer for direct-chat user surfaces

For direct human conversations, do not emit raw tool-summary banners unless a verbose/debug mode is explicitly enabled.

2. Separate internal diagnostics from user-facing copy

Keep:

• raw command labels
• tool stderr summaries
• jq / bash / heredoc / shell fragments

for logs and diagnostics only, not for the chat surface.

3. Introduce a single user-facing failure translation policy

Normalize these families into a smaller set of user-facing outcomes such as:

• task still running / retrying
• task failed before starting
• task partially completed
• session recovery needed

instead of mixing raw banner forms.

4. Avoid false failures on success-path turns

If the assistant reply or artifact already exists, do not later emit run ... failed style copy for an internal polling or bookkeeping mistake.

5. Improve tool-label sanitization

If a label must be shown, sanitize/truncate it safely:

• no raw heredoc fragments
• no broken regex/jq snippets
• no huge shell commands
• no misleading task names that obscure the real root cause

Evidence sources

Local evidence came from:

• ~/.openclaw/workspace/memory/2026-05-20-0845.md
• ~/.openclaw/workspace/memory/2026-05-21-1516.md
• ~/.openclaw/workspace/memory/2026-05-22-1500.md
• ~/.openclaw/workspace/memory/2026-05-26-0911.md
• ~/.openclaw/workspace/memory/2026-05-26-1636.md
• ~/.openclaw/workspace/memory/2026-05-27-0851.md
• ~/.openclaw/workspace/memory/2026-05-27-1732.md
• ~/.openclaw/workspace/memory/2026-06-01-1425.md
• ~/.openclaw/workspace/memory/2026-06-01-1845.md
• ~/.openclaw/workspace/memory/2026-06-01-1911.md
• ~/.openclaw/agents/main/sessions/sessions.json
• related trajectories/session artifacts cited in #89245

Impact

Medium to high.

The issue does not always destroy the underlying task, but it repeatedly damages user trust:

• tasks that succeeded look failed
• transient debug commands look like product failures
• generic fallbacks hide the real state
• repeated banners make the assistant feel unstable even when some work finished