Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Codex-native command/read/search status projection can turn expected negative checks and internal probe failures into channel-visible OpenClaw failed messages. The visible reports are channel-specific, but the likely ownership boundary is the Codex/OpenClaw integration path that converts native Codex item status into lastToolError and then into user-facing warning payloads.

Steps to reproduce

Evidence-backed paths:

1. In [Bug]: Telegram shows internal "⚠️ 🛠️ ... failed" for normal grep exit(1) after upgrade to 2026.5.20 #87610, run OpenClaw 2026.5.20 with the Codex runtime through Telegram.
2. Let the agent execute a shell search pipeline where grep exits 1 because no rows matched.
3. Observe Telegram receive a visible ⚠️ ... failed banner even though the no-match result was the expected negative check.
4. In [Bug]: 2026.5.19 Discord shows failed file reads in chat #85310, run the Codex runtime through Discord scheduled/group delivery and let the agent attempt an internal file read for a missing per-run memory or skill file.
5. Observe Discord receive a visible ⚠️ ... print lines ... failed message.

Current-source path to inspect:

1. extensions/codex/src/app-server/event-projector.ts:1058 maps non-success Codex-native result status to isError.
2. extensions/codex/src/app-server/event-projector.ts:1098 records that native failure as lastNativeToolError.
3. extensions/codex/src/app-server/event-projector.ts:1985 treats every native commandExecution as a mutating tool item.
4. src/agents/embedded-agent-runner/run/payloads.ts:517 formats lastToolError as a channel-visible ⚠️ ... failed warning.

Expected behavior

The Codex/OpenClaw integration should distinguish real user-action failures from expected negative checks and internal agent probes before producing channel-visible failure warnings.

Expected-negative checks such as search-no-match should be allowed to produce a normal result without an alarming failure banner. Internal agent probes that miss optional workspace files should remain internal diagnostics unless the assistant deliberately reports them or the failure blocks the requested user action.

This should be channel-agnostic. Telegram and Discord may need output-suppression safeguards, but they should not be the primary owners of Codex-native tool status semantics.

Actual behavior

Prior reports show channel-visible ⚠️ ... failed messages for Codex-backed operations that are not necessarily user-action failures:

• [Bug]: Telegram shows internal "⚠️ 🛠️ ... failed" for normal grep exit(1) after upgrade to 2026.5.20 #87610: Telegram shows a visible failed-tool banner for a shell search where grep exit 1 means no matches.
• [Bug]: 2026.5.19 Discord shows failed file reads in chat #85310: Discord showed visible print lines ... failed messages for missing internal read targets in a Codex-backed workflow. Fix heartbeat message-tool delivery policy #85357 fixed the specific Discord heartbeat delivery-policy gap, but the report still shows the same Codex-native failure shape.
• [Bug]: Internal messages surface in Telegram chat #88128: Telegram has a separate open report for internal runtime artifacts surfacing in chat, which is adjacent evidence that external channels can expose runtime/internal messages when upstream semantics or suppression are too broad.

Current source suggests the shared path is Codex-native event projection plus OpenClaw warning payload construction, not Telegram alone.

OpenClaw version

Observed reports: 2026.5.19, 2026.5.20, and adjacent Telegram internal-message evidence on 2026.5.26. Current source reviewed on main at b13fb788b53 on 2026-05-30.

Operating system

Observed reports include macOS and Ubuntu. The suspected source path is OS-independent.

Install method

Observed reports include npm global and source checkout.

Model

openai/gpt-5.5 / gpt-5.5 with the Codex runtime.

Provider / routing chain

OpenClaw -> @openclaw/codex -> external channel delivery, including Telegram and Discord reports.

Additional provider/model setup details

This issue intentionally reframes the visible channel reports as a shared Codex/OpenClaw integration problem. The channel issues should remain useful repro anchors, but the product decision should likely happen at the native tool-status boundary:

• Which Codex-native outcomes should become lastToolError?
• Which native command outcomes are mutating or user-action failures?
• When should src/agents/embedded-agent-runner/run/payloads.ts add a fallback ⚠️ ... failed warning?
• Should this align with OpenClaw's own tool semantics, where src/agents/sessions/tools/grep.ts:353 treats no matches as a successful No matches found result and src/agents/bash-tools.exec-runtime.ts:546 treats normal non-shell nonzero exits as completed with an exit-code note?

Logs, screenshots, and evidence

Related issues:

• [Bug]: Telegram shows internal "⚠️ 🛠️ ... failed" for normal grep exit(1) after upgrade to 2026.5.20 #87610: Telegram shows internal ⚠️ ... failed for normal grep exit 1 after upgrade to 2026.5.20.
• [Bug]: 2026.5.19 Discord shows failed file reads in chat #85310: Discord showed failed Codex-backed file-read messages in chat on 2026.5.19 and 2026.5.20; fixed for the Discord heartbeat delivery-policy path by Fix heartbeat message-tool delivery policy #85357.
• [Bug]: Internal messages surface in Telegram chat #88128: Telegram surfaces internal runtime messages in chat.

Current source refs:

• extensions/codex/src/app-server/event-projector.ts:1058
• extensions/codex/src/app-server/event-projector.ts:1098
• extensions/codex/src/app-server/event-projector.ts:1985
• src/agents/embedded-agent-runner/run/payloads.ts:517
• src/agents/sessions/tools/grep.ts:353
• src/agents/bash-tools.exec-runtime.ts:546

Impact and severity

Affected: users on external messaging channels when the Codex runtime produces native tool statuses that OpenClaw turns into visible warnings.

Severity: Medium UX regression, with possible information-exposure risk when internal file/probe details are shown in shared channels.

Frequency: Reproducible for the grep/no-match shape in #87610; observed across multiple missing-read examples in #85310.

Consequence: Users see false or overly alarming failure messages, routine negative checks look broken, and internal agent activity can leak into chat surfaces.

Additional information

This should not be solved as a grep-string special case or a Telegram-only sanitizer. The likely durable fix is a small, explicit Codex-native status mapping policy plus fallback-warning policy tests, with channel tests only proving that external delivery no longer leaks the misclassified internal/expected outcomes.