openclaw - 💡(How to fix) Fix [Regression] OpenClaw 2026.5.22: Codex app-server / plugin approval stalls cause interrupted turns and tool-execution timeouts in Nextcloud Talk agent sessions

This issue is being filed on behalf of the human operator by an AI agent running OpenClaw 2026.5.12 after rollback.

Summary

After updating OpenClaw from 2026.5.12 to 2026.5.22 on 2026-05-24, Codex native agent behavior degraded in a live Nextcloud Talk group session.

The same user workflow had been stable on 2026.5.12. Similar degraded behavior was also observed by the operator on 2026.5.18, 2026.5.19, 2026.5.20, and 2026.5.22.

The configured model was Codex GPT-5.5 with thinking=xhigh.

Environment

• Host: macOS gateway, Node 25.8.1
• OpenClaw before update: 2026.5.12 (f066dd2)
• OpenClaw after update: 2026.5.22 (a374c3a)
• Channel: Nextcloud Talk group room
• Agent: main
• Model: openai/gpt-5.5, thinking=xhigh, fast=off
• Time window investigated: 2026-05-24 18:58-20:38 JST

Update log evidence:

OpenClaw update helper started: 2026-05-24 18:57:19 JST
Current version:
OpenClaw 2026.5.12 (f066dd2)
targetVersion: "2026.5.22"
Update Result: OK
Before: 2026.5.12
After: 2026.5.22
OpenClaw 2026.5.22 (a374c3a)

Log file used:

/tmp/openclaw/openclaw-2026-05-24.log
/Users/<user>/TempWork/ai03/Logs/openclaw_update_20260524_185719.log
/Users/<user>/TempWork/ai03/Logs/openclaw_post_update_sentinel_20260524_185946.log

User-visible symptoms

1. Previously routine tasks stopped working after the update.
2. The assistant could send an initial reply, but then failed to reliably execute the requested task.
3. When multiple instructions were given, the assistant effectively handled only one or responded to the wrong part.
4. The assistant appeared to lose context and behave much less intelligently than on 2026.5.12.
5. Task management became unreliable: a "memory loss prevention" follow-up cron repeatedly timed out and appeared as an error.
6. Replies were posted to the wrong thread / context during the incident, requiring user correction.
7. The issue was severe enough that the operator restored back to 2026.5.12 at 20:38 JST.

Timeline and evidence

18:58-18:59 Update succeeds

The update completed successfully and the gateway reported 2026.5.22.

18:58:25 Update Result: OK
Before: 2026.5.12
After: 2026.5.22
18:59:04 agent model: openai/gpt-5.5 (thinking=xhigh, fast=off)

19:00 Native Codex thread is forcibly refreshed

Immediately after the update, the active Nextcloud Talk session exceeded the native transcript token threshold and OpenClaw started a fresh thread.

19:00:22 WARN codex app-server native transcript exceeded active token limit; starting a fresh thread
sessionKey=agent:main:nextcloud-talk:group:<room>
maxTokens=70000
sessionTokens=88140
nativeTokens=88146

This is the suspected turning point for context loss. The observed behavior after this point was consistent with the assistant losing operational context and failing to continue multi-step work reliably.

19:40-20:22 Turn completion events no longer match the active turn

The log repeatedly reports completed/interrupted turns arriving for a different active thread/turn.

Count in the investigated window: 6 occurrences.

Examples:

19:40:43 WARN codex app-server turn/completed did not match active turn
activeThreadId=019e5992-7d34-76d1-9643-29585470e65b
activeTurnId=019e5992-7d76-7313-9923-5aa7c323a578
threadId=019e596d-bcbf-7b73-8547-6e862fcf220b
nestedTurnId=019e5990-5ebf-7b83-aec0-ab08ba20a6f3
turnStatus=interrupted
matchesActiveThread=false
matchesActiveTurn=false

20:22:33 WARN codex app-server turn/completed did not match active turn
turnStatus=completed
turnItemCount=0
matchesActiveThread=false
matchesActiveTurn=false

This correlates with the user-visible symptom where the assistant replied but did not reliably complete the requested action, and where later instructions appeared to collide with previous turns.

19:42-20:16 Cron-based task execution repeatedly times out

A follow-up cron created for "物忘れ防止: OpenClaw更新後確認" repeatedly timed out. This was a simple recurring task expected to run every five minutes.

Count in the investigated window:

• cron cleaned up timed-out agent run: 5
• cron job run returned error status: 5

Examples:

19:42:31 WARN cron: cleaned up timed-out agent run
jobId=a5517edf-5bb0-424f-b13a-e2c4128772d3
sessionId=3c9db227-9f36-49ab-804e-4d7fbe991f31
aborted=true
drained=true

19:42:31 WARN cron: job run returned error status
jobName=物忘れ防止: OpenClaw更新後確認
error=cron: job execution timed out (last phase: tool-execution-started)

The same pattern repeated at 19:47, 19:52, 19:59, and 20:16.

Note: this cron job was accidentally registered during the incident and is not claimed as the root cause. It is included as supporting evidence because it repeatedly timed out at the tool-execution-started phase, matching the broader symptom that tool/task execution was not completing on 2026.5.22.

At 20:06, the user-visible cron list showed the task in error state:

a5517edf-5bb0-424f-b13a-e2c4128772d3 物忘れ防止: OpenClaw更新後確認 every 5m ... error isolated not requested

19:53-20:04 Queue / liveness warnings appear while the Talk session is active

19:53:22 WARN liveness warning: reasons=event_loop_delay ... queued=3
work=[queued=agent:main:nextcloud-talk:group:<room>(... q=3 ...)]

20:04:22 WARN liveness warning: reasons=event_loop_delay ... eventLoopDelayMaxMs=7285.5 ... queued=5
work=[queued=agent:main:nextcloud-talk:group:<room>(... q=5 ...)]

This correlates with user-visible delayed responses and failure to process multiple instructions reliably.

19:55 and 20:04 Codex turn idle timeouts retire the app-server client

Count in the investigated window:

• turn idle timeout: 2
• client retired after timed-out turn: 2
• auth profile timeout: 1
• failover decision surfaced as error: 1

Examples:

19:55:05 WARN codex app-server turn idle timed out waiting for completion
idleMs=60000
timeoutMs=60000
lastActivityReason=request:item/fileChange/requestApproval:response

19:55:05 WARN codex app-server client retired after timed-out turn
reason=turn_completion_idle_timeout
clearedSharedClient=true

19:55:05 WARN Profile openai-codex:<codex-oauth-profile> timed out. Trying next account...
19:55:05 WARN embedded run failover decision
decision=surface_error
failoverReason=timeout
provider=openai-codex
model=gpt-5.5
fallbackConfigured=false
timedOut=true
aborted=true

20:04 Timeout compaction triggers after high prompt token usage

20:04:03 WARN [timeout-compaction] LLM timed out with high prompt token usage (67%); attempting compaction before retry
20:04:16 INFO Compaction safeguard: using session branch messages after compaction preparation omitted real conversation content.
20:05:17 INFO [compaction] rotated active transcript after compaction (sessionKey=agent:main:nextcloud-talk:group:<room>)
20:05:17 INFO [timeout-compaction] compaction succeeded for openai-codex/gpt-5.5; retrying prompt

This is likely related to the observed context loss / degraded reasoning. The log explicitly says compaction preparation omitted real conversation content and had to use session branch messages.

20:23 Hook timeout and lane wait

20:23:03 ERROR [hooks] agent_end handler from skill-workshop failed: timed out after 30000ms
20:23:03 WARN lane wait exceeded: lane=session:agent:main:cron-ai-chan-mail-hourly-check waitedMs=30115 queueAhead=0 activeAhead=1 activeNow=0 queueBehind=0

This indicates that post-run hooks and session lanes were also blocked or timing out during the degraded period.

20:38 Restore to 2026.5.12 begins

The operator restored back to 2026.5.12.

OpenClaw restore helper started: 2026-05-24 20:38:01 JST
Restore snapshot source: /Users/<user>/.openclaw/workspace/ai03/Backups/openclaw_update_20260524_185719
npm install -g [email protected]
Pinning core npm plugins to OpenClaw 2026.5.12
OpenClaw 2026.5.12 (f066dd2)

Error counts in 18:58-20:38 JST window

• plugin.approval.waitDecision responses taking about 120s: 34 (max observed: 120609ms)
• Native thread fresh start after token threshold: 1
• turn/completed did not match active turn: 6
• cron cleaned up timed-out agent run: 5
• cron job run returned error status: 5
• Codex turn idle timed out waiting for completion: 2
• Codex app-server client retired after timed-out turn: 2
• openai-codex profile timed out: 1
• timeout-compaction events: 2
• liveness warnings with queued work: 2
• skill-workshop agent_end hook timeout: 1
• lane wait exceeded: 1

A/B comparison against restored 2026.5.12

This section compares 2026.5.22 against the restored 2026.5.12 state from four angles, using local logs and task files.

1. Same-instruction first response latency

Direct Talk-side response latency was not fully reconstructed from the available local logs, so this point is not claimed as a precise user-message latency measurement.

The closest local proxy evidence is still strong: during the 2026.5.22 window, OpenClaw logged 34 plugin approval waits at about 120 seconds each, plus queue/lane warnings. In the post-restore 2026.5.12 check window from 20:39-21:13 JST, the same log patterns were not observed.

This supports the user-visible impression that 2026.5.22 became much slower or appeared stopped, but the exact first-response delta should be measured with Talk message timestamps if needed.

2. Tool/plugin approval wait time

2026.5.22 showed repeated approval wait stalls:

19:02:55 plugin.approval.waitDecision 119965ms
19:12:44 plugin.approval.waitDecision 119969ms
19:18:55 plugin.approval.waitDecision 119965ms
20:36:15 plugin.approval.waitDecision 119940ms / 119942ms

Count in the 18:58-20:38 JST 2026.5.22 window: 34. Maximum observed wait: 120609ms.

Count in the 20:39-21:13 JST post-restore 2026.5.12 window: 0.

This is one of the clearest measurable differences between the failing 2026.5.22 period and the restored 2026.5.12 period.

3. Whether status.json / registry.json were actually updated

During the 2026.5.22 period, a simple recurring follow-up task repeatedly failed before it could finish tool execution:

cron: job execution timed out (last phase: tool-execution-started)

The affected job was the “物忘れ防止: OpenClaw更新後確認” job. It repeatedly entered timeout/error states and did not behave like a normal reminder/task tracking path.

After restoring to 2026.5.12, task tracking writes were observed working again in this workspace:

• “物忘れ防止タスク登録” was registered, then approval/delete was applied.
• The issue report task status file and task registry were updated and visible to the progress widget.
• The current issue report task status was manually refreshed after a stale update was detected, and the widget returned to “進行中”.

This does not prove that every 2026.5.22 status write was impossible, but it does show that 2026.5.22 repeatedly failed at the tool-execution boundary where those writes should have happened, while 2026.5.12 handled the same class of task tracking workflow successfully after restore.

4. activeThread / activeTurn mismatch

2026.5.22 logged active turn mismatches after the native fresh-thread event:

19:40:43 codex app-server turn/completed did not match active turn
20:22:33 codex app-server turn/completed did not match active turn
20:22:45 codex app-server turn/completed did not match active turn

Count in the 18:58-20:38 JST 2026.5.22 window: 6.

Count in the 20:39-21:13 JST post-restore 2026.5.12 window: 0.

This matches the observed symptom where the assistant could reply in the room but then fail to continue the actual command, or answer only one part of a multi-part instruction. A completion belonging to a non-active turn is exactly the type of state mismatch that can make the conversation appear incoherent even when the model itself is capable.

Comparison conclusion

The additional four-angle comparison strengthens the main conclusion: the regression is more consistent with OpenClaw execution/session plumbing failure than with GPT-5.5/xHigh becoming less capable.

The same configured model behaved acceptably on 2026.5.12 after restore, while 2026.5.22 showed repeated approval waits, tool-execution-started cron timeouts, active turn mismatches, timeout-compaction, and client retirement.

Expected behavior

• Updating from 2026.5.12 should not cause an active Talk/Codex session to lose functional context.
• After sending a reply, the assistant should still execute the requested task.
• Multiple user instructions in the same room should be handled in order, or explicitly acknowledged if one supersedes another.
• Cron agent turns should not repeatedly time out at tool-execution-started for a simple follow-up task.
• turn/completed events should match the active turn, or stale completions should be safely ignored without disrupting the current turn.
• Compaction/fresh-thread behavior should preserve enough conversation and system context for the assistant to keep following operational rules.

Actual behavior

• The active Talk session hit the 70k native transcript threshold immediately after update and OpenClaw started a fresh native thread.
• After that, turns began completing against non-active thread/turn IDs.
• Cron follow-up runs repeatedly timed out at tool-execution-started.
• Codex app-server turns timed out and retired the shared client.
• Timeout compaction occurred, with a safeguard log indicating that compaction preparation omitted real conversation content.
• The assistant failed to reliably execute after replying, mishandled task management, and confused reply context.

Suspected regression area

The strongest evidence points to interaction between:

• Codex native thread token threshold / fresh-thread creation
• active turn tracking after fresh-thread or compaction
• timeout-compaction behavior
• queue/lane handling for Nextcloud Talk sessions and cron agent turns
• post-run hook handling under timeout pressure

A previous local diff investigation found that the native thread active token limit / fresh-thread behavior was introduced after 2026.5.12, and was present by the later 2026.5.x builds. 2026.5.12 did not have the same observed behavior in this environment.

Impact

High severity for long-running assistant operations.

This breaks a core use case: a long-lived Nextcloud Talk assistant room with operational memory, recurring tasks, and multi-step commands. The assistant can appear to answer, but then fail to perform the command or lose task context, which is worse than a hard failure because the user may believe work is proceeding.

Privacy note

Some local filesystem paths, hostnames, user/account names, and room/session identifiers were redacted from this public report. Raw logs can be provided privately if needed.