Bug type

Behavior bug / reliability regression: Codex-backed turns repeatedly do work but never reach terminal turn/completed, causing Telegram sessions to fail before delivering the requested final answer.

Summary

After updating to OpenClaw 2026.5.27, multiple Telegram conversations backed by the native Codex runtime started repeatedly failing with:

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

The visible fallback text is not the main problem. The main problem is that the underlying Codex app-server turns are repeatedly not completing. The agent performs tool calls and writes/reads files, but then OpenClaw waits 60s for a terminal completion event and ends the turn as an error. The user receives no useful final answer and cannot tell which work actually completed.

This started suddenly on 2026-05-28 after the .27 update path. It was not seen by this operator earlier in the morning, and it persisted after gateway restarts and session resets.

Environment

• OpenClaw: 2026.5.27 (27ae826)
• Codex CLI: codex-cli 0.134.0
• Runtime/provider: openai-codex / gpt-5.5
• Channel: Telegram
• Surfaces affected locally:
  • Telegram direct DM session
  • Telegram group/forum topic sessions, including WC Hub / project-style topic lanes
• OS: macOS
• Install method: npm/global Homebrew path
• Local check time: 2026-05-28 10:55 PDT

Observed behavior

Across several Telegram sessions, the same pattern repeats:

1. User sends a normal request.
2. Codex starts the turn and performs tool calls.
3. OpenClaw receives item/completed or rawResponseItem/completed notifications.
4. No terminal turn/completed arrives.
5. After ~60s idle, OpenClaw records turn.completion_idle_timeout.
6. Session ends with:

promptError="codex app-server turn idle timed out waiting for turn/completed"

Telegram then receives the fallback:

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

This is happening repeatedly enough that the Telegram agent is effectively unusable for work that requires a complete final answer.

Local evidence

The following are redacted/summarized trajectory records from the affected machine. Message text, private paths, and tool outputs are intentionally omitted.

Telegram direct DM

Session trajectory:

ad9bca5d-5ba6-46d6-b7f5-a58953dd6925.trajectory.jsonl

Failure 1:

{
  "ts": "2026-05-28T17:31:21.148Z",
  "type": "turn.completion_idle_timeout",
  "data": {
    "idleMs": 60002,
    "timeoutMs": 60000,
    "lastActivityReason": "notification:rawResponseItem/completed",
    "lastNotificationMethod": "rawResponseItem/completed",
    "lastNotificationItemType": "reasoning"
  }
}
{
  "ts": "2026-05-28T17:31:21.162Z",
  "type": "session.ended",
  "data": {
    "status": "error",
    "timedOut": true,
    "yieldDetected": false,
    "promptError": "codex app-server turn idle timed out waiting for turn/completed"
  }
}

Failure 2, same Telegram DM session:

{
  "ts": "2026-05-28T17:42:24.235Z",
  "type": "turn.completion_idle_timeout",
  "data": {
    "idleMs": 60002,
    "timeoutMs": 60000,
    "lastActivityReason": "notification:item/completed",
    "lastNotificationMethod": "item/completed"
  }
}
{
  "ts": "2026-05-28T17:42:24.258Z",
  "type": "session.ended",
  "data": {
    "status": "error",
    "timedOut": true,
    "yieldDetected": false,
    "promptError": "codex app-server turn idle timed out waiting for turn/completed"
  }
}

Telegram group/topic lane

Session trajectory:

af32871a-35c1-4d38-aa7c-77796dfa90c2-topic-2.trajectory.jsonl

Failure:

{
  "ts": "2026-05-28T17:36:59.978Z",
  "type": "turn.completion_idle_timeout",
  "data": {
    "idleMs": 60003,
    "timeoutMs": 60000,
    "lastActivityReason": "notification:rawResponseItem/completed",
    "lastNotificationMethod": "rawResponseItem/completed",
    "lastNotificationItemType": "reasoning"
  }
}
{
  "ts": "2026-05-28T17:37:00.000Z",
  "type": "session.ended",
  "data": {
    "status": "error",
    "timedOut": true,
    "yieldDetected": false,
    "promptError": "codex app-server turn idle timed out waiting for turn/completed"
  }
}

Another Telegram topic lane

Session trajectory:

828f2f78-cb55-45ac-810d-65ea5ba34803-topic-4412.trajectory.jsonl

Failure 1:

{
  "ts": "2026-05-28T17:44:13.493Z",
  "type": "turn.completion_idle_timeout",
  "data": {
    "idleMs": 60003,
    "timeoutMs": 60000,
    "lastActivityReason": "notification:item/completed",
    "lastNotificationMethod": "item/completed"
  }
}
{
  "ts": "2026-05-28T17:44:13.499Z",
  "type": "session.ended",
  "data": {
    "status": "error",
    "timedOut": true,
    "yieldDetected": false,
    "promptError": "codex app-server turn idle timed out waiting for turn/completed"
  }
}

Failure 2:

{
  "ts": "2026-05-28T17:48:24.321Z",
  "type": "turn.completion_idle_timeout",
  "data": {
    "idleMs": 60002,
    "timeoutMs": 60000,
    "lastActivityReason": "notification:rawResponseItem/completed",
    "lastNotificationMethod": "rawResponseItem/completed",
    "lastNotificationItemType": "reasoning"
  }
}
{
  "ts": "2026-05-28T17:48:24.328Z",
  "type": "session.ended",
  "data": {
    "status": "error",
    "timedOut": true,
    "yieldDetected": false,
    "promptError": "codex app-server turn idle timed out waiting for turn/completed"
  }
}

Broader local pattern

Summary scan over recent trajectory files since 2026-05-28T16:20Z found repeated turn.completion_idle_timeout events in multiple session files. Examples:

• 2837a995-eb27-4630-b5b9-00c16ad3b5f2.trajectory.jsonl
  • timeouts at 16:43:28Z, 16:46:56Z, 16:58:34Z, 17:08:45Z
• 688b07c4-9c4d-46ec-8c15-f9883b60db1d-topic-2.trajectory.jsonl
  • timeouts at 16:31:19Z, 16:41:34Z, 16:47:04Z, 16:57:05Z, 17:01:21Z, 17:09:17Z
• ad9bca5d-5ba6-46d6-b7f5-a58953dd6925.trajectory.jsonl
  • timeouts at 17:31:21Z, 17:42:24Z
• af32871a-35c1-4d38-aa7c-77796dfa90c2-topic-2.trajectory.jsonl
  • timeout at 17:36:59Z
• 828f2f78-cb55-45ac-810d-65ea5ba34803-topic-4412.trajectory.jsonl
  • timeouts at 17:44:13Z, 17:48:24Z

Several successful turns appear in the same window, so this is not a total gateway outage or Telegram delivery outage. The failure mode is intermittent/recurrent Codex turn lifecycle non-completion.

Why this is not just the visible fallback-copy issue

The user-visible fallback is helpful because otherwise the operator would see only silence. The underlying problem is not that Telegram displays the fallback; the problem is that the Codex app-server turn repeatedly reaches item/completed / rawResponseItem/completed but does not emit terminal turn/completed.

Suppressing or rewording the channel message would not fix the operational failure: requested work still does not reliably complete, and the user does not receive the final answer.

Expected behavior

Codex-backed Telegram turns should reliably reach a terminal state:

• If the model/tool turn completed, OpenClaw should receive or synthesize a safe terminal completion and deliver the assistant's final text.
• If the Codex app-server/runtime failed, the session should record a precise runtime failure with enough metadata to distinguish:
  • model emitted no final text;
  • app-server stream ended without turn/completed;
  • tool lifecycle remained active;
  • auth/app-server client was closed;
  • gateway watchdog aborted the run.
• Repeated failures across /new, session resets, and gateway restarts should not leave the operator in a loop of partial side effects and no final answer.

Actual behavior

OpenClaw repeatedly ends the run as:

status=error
timedOut=true
yieldDetected=false
promptError="codex app-server turn idle timed out waiting for turn/completed"

The fallback is delivered to Telegram, but the original requested work is left in an uncertain partial state.

Related issues / prior art

Possibly related, but this report is specifically about repeated non-completion in Telegram, not merely fallback text visibility:

• Codex missing-terminal fallback leaks into Discord channel on 2026.5.27 despite #87079 #87725 - visible Codex missing-terminal fallback in channel on 2026.5.27
• [Bug]: Empty assistant delivery (footer-only, "— out" usage) on first turn after /new on Telegram-routed topic lane — 2026.5.27 #87711 - Telegram topic lane empty/unfinished delivery after /new on 2026.5.27
• [Bug]: Spurious "Something went wrong" and Codex app-server failures in large Telegram direct sessions #87299 - Codex app-server failures in large Telegram direct sessions
• [Bug]: GitHub Copilot anthropic-messages transport silently hangs ~365s in isolated cron sessions (2026.5.27) #87692 - watchdog/hang/non-delivery pattern on 2026.5.27 in another transport path
• fix(codex): backport shared app-server startup cleanup to .27 #87428 - .27 backport touching shared Codex app-server startup cleanup; notes live Codex auth failure was not tested

Operator impact

High. From the operator perspective, OpenClaw became unreliable for normal Telegram work:

• Repeated same fallback across DM and topic conversations.
• Work may partially execute but final answer never arrives.
• Gateway restarts and session resets did not reliably resolve it.
• The user cannot trust whether work completed, especially where tool calls modified files or external state.

Suggested investigation direction

Please investigate the Codex app-server lifecycle path where OpenClaw receives item/completed or rawResponseItem/completed but never receives turn/completed.

Useful questions:

• Is .27 losing terminal turn events after completed reasoning/message items?
• Can the app-server emit rawResponseItem/completed or item/completed while still never completing the turn?
• Are shared Codex client/app-server restarts, auth profile churn, or thread rebinding causing terminal events to be dropped?
• Can OpenClaw distinguish "completed assistant item with no active items" from "turn still active" more robustly?
• Should the watchdog preserve more metadata about active item counts/tool lifecycle at timeout?

The important fix target is reliable terminal completion or precise runtime failure classification, not hiding the Telegram fallback text.