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
-
Start OpenClaw 2026.5.12 on macOS with the main agent using:
- Primary:
openai-codex/gpt-5.4
- Fallback:
openai/gpt-5.4
-
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.
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
Start OpenClaw 2026.5.12 on macOS with the main agent using:
openai-codex/gpt-5.4openai/gpt-5.4Confirm 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 \ --json3.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 statusshows: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 settlinImpact and severity
openclaw-diagnostics-2026-05-15T10-11-10-772Z-20049.zip
Affected users/systems/channels:
Severity:
Frequency:
Consequence:
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:
openclaw dashboard --no-open.openclaw gateway status --deepshows Gateway running and connectivity probe OK.openai-codex/gpt-5.4no-tool embedded run works.openai/gpt-5.4no-tool embedded run works.038b7036-68f1-40ca-9fe7-864978445f87(“Obsidian sync health check”) was disabled after it repeatedly timed out and contributed to queued/stuck runs.openclaw system heartbeat disable --jsonreturned{ "ok": true, "enabled": false }openclaw system heartbeat lastreturnednullopenclaw plugins doctorreports “No plugin issues detected.”openclaw gateway stopstopped the LaunchAgent cleanly, and after stoppgrep -af "openclaw.*gateway|node .*openclaw/dist/index.js gateway"returned no Gateway process.