Summary

A Codex app-server turn can idle for the default 60s while OpenClaw is waiting for turn/completed, then abort with turn.completion_idle_timeout. On the next user-facing turn, the context is surfaced as if the user interrupted the turn, which is misleading. In the observed cases, the trajectory log shows an app-server idle timeout rather than a manual user interruption.

Environment

• OpenClaw: 2026.5.28 (e932160)
• npm latest checked at report time: 2026.5.28
• Host: macOS / OpenClaw main agent
• Channel: WebChat direct conversation
• Codex plugin config: appServer.experimental.sandboxExecServer: true
• No turnCompletionIdleTimeoutMs override configured, so the documented default 60000 ms applies
• Dynamic tools loading: searchable

Expected behavior

After a successful tool result or accepted turn, Codex/OpenClaw should either:

1. continue with the next assistant response/tool call, or
2. send turn/completed if the turn is finished.

If the watchdog timeout fires, the next prompt/context should distinguish an app-server idle timeout from an actual user interruption.

Actual behavior

The turn is aborted after 60s idle while waiting for turn/completed. The following user-facing context reports the previous turn as interrupted by the user, even though the trajectory shows turn.completion_idle_timeout and promptError: "codex app-server turn idle timed out waiting for turn/completed".

Observed evidence

Sanitized trajectory excerpts:

2026-06-03T12:40:41.362Z turn.completion_idle_timeout
  idleMs=60002 timeoutMs=60000
  lastActivityReason=notification:item/completed
  lastNotificationMethod=item/completed

model.completed
  timedOut=true aborted=true
  promptError="codex app-server attempt timed out"

session.ended
  status="error"
  promptError="codex app-server turn idle timed out waiting for turn/completed"

Additional repeated occurrences from the same runtime session:

2026-06-03T12:44:37.385Z turn.completion_idle_timeout idleMs=60003 timeoutMs=60000
2026-06-03T13:06:38.861Z turn.completion_idle_timeout idleMs=60002 timeoutMs=60000

There were also earlier occurrences around 2026-06-03T11:58:46.722Z and 2026-06-03T12:11:41.745Z, including a case where the last activity was notification:rawResponseItem/completed.

Reproduction shape

Observed during a multi-step skill-authoring workflow:

1. User asks the main agent to continue or create a skill.
2. Agent performs successful tool calls such as reading local skill files or creating empty local directories.
3. The final tool event completes successfully.
4. No assistant response or next tool call is emitted for about 60s.
5. OpenClaw emits turn.completion_idle_timeout and aborts the turn.
6. The next user-facing context describes the previous turn as a user interruption.

One observed case timed out after the user asked the agent to continue, before any visible assistant text/tool call was produced, again with the same turn.completion_idle_timeout signature.

Impact

This silently stops multi-step work and makes the user believe they interrupted the agent when they did not. It also leaves partial local state behind, for example empty scaffolding directories created before the aborted turn, and forces repeated task restarts.

Suspected cause / fix direction

This may be two related issues:

1. The Codex app-server path sometimes does not emit turn/completed after a completed tool handoff or accepted turn.
2. The user-facing recovery context maps the idle-aborted turn to a generic user interruption message.

The documented config workaround appears to be increasing appServer.turnCompletionIdleTimeoutMs and possibly appServer.postToolRawAssistantCompletionIdleTimeoutMs, but that only mitigates slow quiet phases. If turn/completed is never emitted, the underlying issue still remains.

What was checked

• Confirmed the installed OpenClaw version matches the latest npm version at report time.
• Confirmed no local timeout override was configured.
• Confirmed the local docs describe turnCompletionIdleTimeoutMs defaulting to 60000 and recommend raising it for slow post-tool/status-only synthesis phases.
• The report is intentionally sanitized and excludes user account data, organization names, secrets, and private file contents.