Summary

OpenClaw's Codex app-server turn-completion watchdog can fire when the assistant emits a status/progress sentence as a rawResponseItem/completed notification, then stays internally silent for more than 60s before the next tool call or turn/completed.

This showed up in daily isolated cron runs that had already completed research tool calls. The last visible assistant output was a transitional sentence like "I'm writing the report...", but no write tool call or terminal event followed within the hardcoded 60s window, so OpenClaw aborted the attempt.

Environment

• OpenClaw: 2026.5.4 (325df3e)
• Codex plugin package: @openclaw/[email protected]
• Provider/model: openai-codex/gpt-5.5
• Runtime: Codex app-server harness (agentRuntime.id=codex, agentHarnessId=codex)
• Workload: isolated scheduled Researcher report crons with web research + markdown write/copy/verify phase

Observed failing sessions

Two independent cron sessions failed with the same shape:

1. f415c132-e0b2-434b-884d-1121468d394e

   • Cron: Daily Researcher OpenClaw Ecosystem Deep Dive
   • Timeout event: turn.completion_idle_timeout
   • Timeout data included idleMs=60000, timeoutMs=60000, lastActivityReason=notification:rawResponseItem/completed
   • Last visible assistant text was a transitional status sentence: "I'm writing the report file now, then I'll copy it..."

2. 3c0be461-1f3b-4dd1-b236-31b2f2c6e126

   • Cron: Daily Researcher AI Industry Briefing
   • Timeout event: turn.completion_idle_timeout
   • Timeout data included idleMs=60000, timeoutMs=60000, lastActivityReason=notification:rawResponseItem/completed
   • Last visible assistant text was a transitional status sentence: "I'm writing the report and then I'll copy and verify all three destinations."

In both cases prompt-token usage was around 54-55% of a 200k context, below the timeout-compaction threshold we found locally, so this did not appear to be the high-token compaction recovery path.

Local code evidence

In the externalized Codex extension bundle:

• /root/.openclaw/extensions/codex/dist/run-attempt-BNbVe-IG.js
• CODEX_TURN_COMPLETION_IDLE_TIMEOUT_MS = 6e4
• The watchdog timeout is resolved via resolveCodexTurnCompletionIdleTimeoutMs(...).
• Activity is touched for notifications via touchTurnCompletionActivity("notification:<method>").
• The last activity reason in both failures was notification:rawResponseItem/completed.

The config schema appears to expose plugins.entries.codex.config.appServer.requestTimeoutMs, but not a field for the turn-completion idle timeout. In local dist/config-CkkoMeqF.js, the appServer config object includes fields such as mode, transport, command, args, url, authToken, headers, clearEnv, requestTimeoutMs, approvalPolicy, sandbox, approvalsReviewer, serviceTier, and defaultWorkspaceDir, but no turnCompletionIdleTimeoutMs knob.

Control probe

We ran a controlled one-off probe with the same general workload shape: web fetches, then a markdown report write/verify phase. The prompt explicitly forbade transitional assistant text before the write phase:

After the research calls finish, your next action must be a bash or file-write tool call that writes the markdown report. Do not announce that you are writing.

Result:

• Session: codex-watchdog-probe-b-20260505T171203Z
• Evidence dir: /root/.openclaw/workspace-tender/tmp/codex-watchdog-probe-b-20260505T171203Z
• Runtime confirmed: openai-codex/gpt-5.5, agentRuntime.id=codex, agentHarnessId=codex
• Duration: 73049ms, longer than the 60s watchdog window
• Tool calls: 13 (web_fetch + bash), failures: 0
• Output report: 8313 bytes
• No turn idle timed out warning observed

This suggests the problematic pattern is not long tool execution itself. Long tool phases emit enough notifications. The risky shape is status-only assistant text followed by internal silence before the next tool call or terminal turn event.

Why this matters

A common assistant behavior is to emit a short status sentence before starting a file write or final synthesis phase. With the Codex app-server watchdog, that sentence can become the last notification and start a 60s idle window even though the model may still be doing useful internal work or preparing the next tool call.

The current workaround is prompt-level mitigation: instruct agents not to announce the write phase and to make the next action a tool call. That works in our probe, but it is brittle and has to be applied to each affected scheduled prompt.

Suggested directions

Possible fixes, either of which would help:

1. Expose the watchdog as config, for example:

{
  "plugins": {
    "entries": {
      "codex": {
        "config": {
          "appServer": {
            "turnCompletionIdleTimeoutMs": 120000
          }
        }
      }
    }
  }
}

1. Revisit how rawResponseItem/completed is treated by the turn-completion watchdog. A completed assistant status item may not mean the turn is now idle in the same way as a lack of app-server notifications; it can be an intermediate model item before the next tool call.

2. Emit a more specific diagnostic when this timeout fires, including the last assistant text/item type and whether the previous event was status-only assistant content versus an active tool call.

Notes

This is related in spirit to prior Codex app-server terminal-notification hardening, but the observed failure here is more specific: terminal events do not merely disappear after turn/start; the app-server emits a non-terminal assistant item (rawResponseItem/completed) and then the watchdog times out waiting for subsequent progress.