Summary
After upgrading from 2026.5.7 to 2026.5.18, Control UI webchat can fail with:
Agent failed before reply: All models failed (4): openai/gpt-5.5: This operation was aborted (timeout) | openai/gpt-5.3-codex: This operation was aborted (timeout) | qwen-portal/coder-model: This operation was aborted (timeout) | openai/gpt-5.2: This operation was aborted (timeout)
The important part is that every fallback candidate receives the same abort/timeout almost immediately. In the failing run, the normal agent/embedded strict-agentic execution contract active log line never appears, suggesting the webchat request timeout fires before the embedded Codex run actually starts.
Environment
- OpenClaw:
2026.5.18 (50a2481)
- macOS: 15.7.4
- Node:
v22.22.0
- Control UI:
openclaw-control-ui webchat vcontrol-ui
- Model config:
openai/gpt-5.5
- Runtime provider in logs:
openai-codex/gpt-5.5
- OAuth/auth-profile mode
Reproduction path observed
- Restart gateway.
- Fully quit browser, reopen Control UI, reload.
- Send a webchat message from Control UI.
- The run eventually returns
All models failed (4) with timeout/aborted for every fallback candidate.
Relevant logs
2026-05-19T12:20:00.052+09:00 info gateway/ws webchat connected conn=d7441f25... client=openclaw-control-ui webchat vcontrol-ui
2026-05-19T12:20:01.764+09:00 info gateway/ws ⇄ res ✓ health 592ms cached=true
2026-05-19T12:20:07.727+09:00 info gateway/ws ⇄ res ✓ commands.list 5125ms
2026-05-19T12:20:07.787+09:00 info gateway/ws ⇄ res ✓ models.list 5184ms
2026-05-19T12:20:08.020+09:00 info gateway/ws ⇄ res ✓ sessions.list 5420ms
2026-05-19T12:20:08.760+09:00 info gateway/ws ⇄ res ✓ chat.history 6160ms
2026-05-19T12:20:09.054+09:00 info gateway/ws ⇄ res ✓ models.authStatus 6454ms
2026-05-19T12:21:37.979+09:00 warn model-fallback/decision runId=77b298a8... candidate=openai/gpt-5.5 reason=timeout errorPreview="This operation was aborted"
2026-05-19T12:21:39.104+09:00 warn model-fallback/decision runId=77b298a8... candidate=openai/gpt-5.3-codex reason=timeout errorPreview="This operation was aborted"
2026-05-19T12:21:47.128+09:00 warn model-fallback/decision runId=77b298a8... candidate=qwen-portal/coder-model reason=timeout errorPreview="This operation was aborted"
2026-05-19T12:21:48.303+09:00 warn model-fallback/decision runId=77b298a8... candidate=openai/gpt-5.2 reason=timeout errorPreview="This operation was aborted"
2026-05-19T12:21:49.876+09:00 error Embedded agent failed before reply: All models failed (4): openai/gpt-5.5: This operation was aborted (timeout) | openai/gpt-5.3-codex: This operation was aborted (timeout) | qwen-portal/coder-model: This operation was aborted (timeout) | openai/gpt-5.2: This operation was aborted (timeout)
Expected behavior
If the first candidate is slow or not started yet, fallback candidates should not all be immediately aborted by the same already-fired webchat abort signal. Either the webchat request timeout should be long enough for agent startup, or fallback should use a fresh per-candidate timeout/abort controller.
Additional notes
CLI runs using the same OpenAI OAuth/Codex harness succeed, which suggests this is not an OAuth or model availability problem:
openclaw agent --agent main --message 'Reply with exactly: OK' --model openai/gpt-5.5 --timeout 180 --json
# status: ok, provider: openai-codex, model: gpt-5.5, fallbackUsed: false
Summary
After upgrading from
2026.5.7to2026.5.18, Control UI webchat can fail with:The important part is that every fallback candidate receives the same abort/timeout almost immediately. In the failing run, the normal
agent/embedded strict-agentic execution contract activelog line never appears, suggesting the webchat request timeout fires before the embedded Codex run actually starts.Environment
2026.5.18 (50a2481)v22.22.0openclaw-control-ui webchat vcontrol-uiopenai/gpt-5.5openai-codex/gpt-5.5Reproduction path observed
All models failed (4)with timeout/aborted for every fallback candidate.Relevant logs
Expected behavior
If the first candidate is slow or not started yet, fallback candidates should not all be immediately aborted by the same already-fired webchat abort signal. Either the webchat request timeout should be long enough for agent startup, or fallback should use a fresh per-candidate timeout/abort controller.
Additional notes
CLI runs using the same OpenAI OAuth/Codex harness succeed, which suggests this is not an OAuth or model availability problem: