openclaw - 💡(How to fix) Fix [Bug]: 2026.5.12 regression: Codex embedded tool/status runs time out while text-only runs succeed

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to OpenClaw 2026.5.12, Codex embedded agent turns that use tool/status checks time out, while text-only turns using the same model route succeed.

Steps to reproduce

1. Start OpenClaw 2026.5.12 on macOS with the main agent using:

   • Primary: openai-codex/gpt-5.4
   • Fallback: openai/gpt-5.4

2. Confirm a text-only embedded Codex run succeeds:

   openclaw agent --local --agent main \
     --model openai-codex/gpt-5.4 \
     -m "Do not use tools. Reply with exactly: codex-text-ok" \
     --timeout 45 \
     --json

3.Run a tool/status-style embedded Codex turn:

openclaw agent --local --agent main
--model openai-codex/gpt-5.4
-m "Use exactly one lightweight tool/status check, then reply with exactly: tool-ok"
--timeout 45
--json

Expected behavior

The tool/status-style run should complete and return tool-ok, or return a concrete tool error. It should not stall until the Codex embedded turn times out.

This workflow worked before the upgrade to 2026.5.12 in the same OpenClaw setup.

Actual behavior

The text-only Codex embedded run succeeds:

codex-text-ok

with JSON showing:

provider=openai-codex model=gpt-5.4 runner=embedded fallbackUsed=false stopReason=stop

The tool/status-style Codex embedded run times out:

[agent/embedded] codex app-server client retired after timed-out turn [agent/embedded] Profile openai:default timed out. Trying next account... [agent/embedded] embedded run failover decision: ... reason=timeout from=openai-codex/gpt-5.4 [diagnostic] lane task error: lane=main ... error="FailoverError: LLM request timed out." [diagnostic] lane task error: lane=session:agent:main:main ... error="FailoverError: LLM request timed out." [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai-codex/gpt-5.4 candidate=openai-codex/gpt-5.4 reason=timeout next=none detail=LLM request timed out. FailoverError: LLM request timed out.

A similar timeout also occurs when forcing openai/gpt-5.4 for a status/version-style check through the embedded runner.

OpenClaw version

2026.5.12

Operating system

macOS 26.2

Install method

npm/pnpm global install, running Gateway as macOS LaunchAgent

Model

openai-codex/gpt-5.4 primary; openai/gpt-5.4 fallback

Provider / routing chain

Primary: OpenClaw -> openai-codex/gpt-5.4 via OAuth/subscription route Fallback: OpenClaw -> openai/gpt-5.4 via API key route Embedded runner: Codex app-server harness

Additional provider/model setup details

openclaw models status shows:

Default : openai-codex/gpt-5.4 Fallbacks (1) : openai/gpt-5.4

openclaw plugins inspect codex shows:

Codex id: codex Status: loaded Version: 2026.5.12 Source: ~/.openclaw/npm/node_modules/@openclaw/codex/dist/index.js Capabilities: text-inference: codex media-understanding: codex The auth profiles include both:

openai-codex OAuth profile openai API key profile

No API keys or tokens are included in this report.

Logs, screenshots, and evidence

Attached diagnostics bundle:

/Users/francois-agent/.openclaw/logs/support/openclaw-diagnostics-2026-05-15T10-11-10-772Z-20049.zip

The diagnostics export reported:

Privacy: payload-free stability, sanitized logs/status/health/config

Key timeout evidence:

[agent/embedded] codex app-server client retired after timed-out turn
[agent/embedded] embedded run failover decision ... reason=timeout from=openai-codex/gpt-5.4
FailoverError: LLM request timed out.

Gateway stability during affected runs showed:

session.stalled outcome=processing reason=active_work_without_progress
activeWorkKind=embedded_run
queueDepth=1

There were also delayed webchat runs where the run completed quickly after it started, but there was a 45–60 second delay before run_started:

message.queued channel=webchat queueDepth=1
diagnostic.liveness.warning reason=event_loop_delay queued=1
eventLoopDelayMaxMs=46271.6
eventLoopUtilization=0.837
cpuCoreRatio=0.862
...
run_started
run_completed
message.processed outcome=completed channel=webchat

During one delayed prompt, the Gateway Node process briefly reached about 99% CPU before settlin

Impact and severity

openclaw-diagnostics-2026-05-15T10-11-10-772Z-20049.zip

Affected users/systems/channels:

• Main OpenClaw webchat session on local Gateway
• Agent turns using the Codex embedded harness
• Prompts where the agent attempts status checks, diagnostics, session inspection, cron/log/config checks, or other tool-like work

Severity:

• High. This blocks normal OpenClaw diagnostic/tool workflows.

Frequency:

• Reproduced repeatedly with tool/status-style prompts.
• Text-only prompts succeed.

Consequence:

• The agent becomes unreliable whenever it decides to inspect state or use tools.
• Practical workaround is to force text-only prompts with “Do not use tools,” but that prevents normal OpenClaw tool workflows.

Additional information

This started after upgrading to OpenClaw 2026.5.12. The same OpenClaw setup was working earlier before the upgrade.

Things checked / ruled out:

• Initial protocol mismatch was fixed by killing an orphan/manual Gateway process and restarting the LaunchAgent-managed Gateway.
• Gateway is now running as a LaunchAgent.
• Gateway version and CLI version both show 2026.5.12.
• Browser auth/token issue was fixed by clearing site data and reconnecting with openclaw dashboard --no-open.
• openclaw gateway status --deep shows Gateway running and connectivity probe OK.
• Text-only embedded agent runs work.
• openai-codex/gpt-5.4 no-tool embedded run works.
• openai/gpt-5.4 no-tool embedded run works.
• Cron job 038b7036-68f1-40ca-9fe7-864978445f87 (“Obsidian sync health check”) was disabled after it repeatedly timed out and contributed to queued/stuck runs.
• Heartbeat was disabled during testing and later confirmed inactive after clean restart:
  • openclaw system heartbeat disable --json returned { "ok": true, "enabled": false }
  • openclaw system heartbeat last returned null
  • Gateway stability showed only startup phase events after clean restart.
• Telegram and Discord channels were temporarily disabled during testing, but the webchat pre-run delay/tool-run timeout pattern persisted.
• Duplicate Discord plugin warning appears frequently, but openclaw plugins doctor reports “No plugin issues detected.”
• openclaw gateway stop stopped the LaunchAgent cleanly, and after stop pgrep -af "openclaw.*gateway|node .*openclaw/dist/index.js gateway" returned no Gateway process.