openclaw - 💡(How to fix) Fix Codex missing-terminal fallback leaks into Discord channel on 2026.5.27 despite #87079

Summary

On 2026.5.27, a Discord channel session using the bundled Codex runtime posted the internal missing-terminal fallback text directly into the user-visible channel:

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

This is not just a turn failure. The user-facing problem is that an internal lifecycle/recovery message was delivered as a normal channel reply, which reads like an assistant response and creates confusing noise in the conversation.

Environment

• OpenClaw: 2026.5.27
• Runtime/channel: Discord channel session
• Agent runtime: OpenAI Codex / bundled Codex plugin
• Model route in use: gpt-5.5 via Codex runtime
• Platform: macOS / launchd gateway
• Installed runtime already includes the #87079 logic (rawResponseItemCompletedWithNoActiveItems / completion idle watchdog)

Observed behavior

At least two archived Discord channel messages on 2026-05-28 contained the exact fallback text above. The latest local incident was around 2026-05-28T16:46:08Z.

The visible symptom was followed by a user complaint because the same class of fallback had appeared repeatedly in the channel.

Local follow-up showed this was a real lifecycle failure path, not intentional assistant content:

• session-lifecycle-audit.py --since-hours 4 initially found one high-severity unrecovered tool-failure lifecycle finding in the implicated session window.
• The finding pointed at an unrecovered tool/native lifecycle failure before the visible fallback. The concrete local evidence included a shell/tool failure (jq: ... null has no keys) during the affected turn.
• A later audit window returned clean after the incident, so this report is about the already-observed channel leak rather than an active stuck session.

Why this is probably not fixed by #87079

#87079 appears to be present in the installed 2026.5.27 Codex runtime. Local installed code contains the expected rawResponseItemCompletedWithNoActiveItems path and arms the completion idle watchdog for the narrow "rawResponseItem/completed but no turn/completed" stall.

That means #87079 may explain why the turn eventually produced fallback/timeout feedback instead of hanging indefinitely, but it does not prevent the user-visible Discord leak.

The current failure mode seems more like:

1. Codex/app-server/tool lifecycle gets into a missing-terminal or unrecovered tool-failure state.
2. buildCodexAppServerPromptTimeoutOutcome() creates a prompt timeout outcome with:
   • replayInvalid: true
   • livenessState: "abandoned"
   • side-effect warning copy when potential side effects are detected.
3. Reply/admission/channel delivery treats that outcome as text suitable for the source Discord channel.
4. The Discord channel receives the internal fallback as if it were a normal assistant reply.

Expected behavior

The system should still protect the user from unsafe automatic replay when side effects may have happened, but the channel UX should not leak the internal lifecycle fallback as ordinary assistant content.

Possible acceptable outcomes:

• surface a channel-safe failure message that clearly says the previous assistant turn failed internally and was not a normal answer;
• route the detailed side-effect/replay metadata to logs/control UI while keeping source-channel text concise;
• mark the turn as failed/abandoned without emitting the current canned fallback into the user channel;
• preserve the "do not auto-replay side-effecting work" behavior.

The important distinction is: keep the safety signal, but do not present Codex lifecycle machinery as chat content.

Related issues / PRs

• Related umbrella: #86047
  • It already contains the exact visible fallback text and covers Codex app-server/lifecycle/tool-execution reliability fallout.
  • This issue is narrower: 2026.5.27, Discord, #87079 already present, user-visible channel leak after missing-terminal/tool lifecycle failure.
• Adjacent fixed stall: #87071 / #87079
  • The installed runtime includes the #87079 code path, so this report should not be closed as simply "fixed by #87079" unless the expected behavior is that the fallback may still be posted to user channels.
• Weaker matches: #87395 / #87331
  • Those focus on Native hook relay unavailable / relay generation staleness. I did not find native-hook-relay evidence in this incident.
• Conceptually adjacent: #87359
  • Similar class of user-facing canned failure leakage, but a different message and channel/success-path shape.

Local code pointers from installed build

These are from the installed 2026.5.27 build rather than a source checkout:

• Codex run-attempt build contains:
  • buildCodexAppServerPromptTimeoutOutcome(...)
  • replayInvalid: true
  • livenessState: "abandoned"
  • CODEX_APP_SERVER_MISSING_TERMINAL_EVENT_SIDE_EFFECT_USER_MESSAGE
  • rawResponseItemCompletedWithNoActiveItems
• OpenClaw reply/admission build reads prompt timeout metadata including livenessState and replayInvalid.

Suggested fix direction

Add a regression test at the source-channel/reply-admission boundary for a Codex app-server missing-terminal timeout outcome with side effects:

• input: prompt timeout outcome with replayInvalid: true, livenessState: "abandoned", and side-effect warning copy;
• channel: Discord/source channel;
• expected: the raw internal fallback string is not emitted as normal assistant text;
• expected: replay remains invalid / not automatically retried;
• expected: enough diagnostic metadata remains available for logs/control UI.

Then adjust the delivery/admission layer or Codex timeout outcome handling so user channels receive intentional channel-safe copy rather than the current internal fallback.