Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix azure-responses/gpt-5.3-codex frequently returns terminal "Unknown error (no error details in response)" (Telegram + non-Telegram runs) [1 pull requests, 2 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#65245•Fetched 2026-04-12 13:24:58
View on GitHub
Comments
2
Participants
1
Timeline
3
Reactions
0
Author
OpenCodeEngineerOpenCodeEngineer
Participants
OpenCodeEngineerOpenCodeEngineer
Timeline (top)
commented ×2cross-referenced ×1

With provider=azure-responses and model=gpt-5.3-codex, many runs terminate as:

Unknown error (no error details in response)

This is repeatedly observed in Telegram group sessions, but logs show the same failure pattern at the same timestamps for non-Telegram runs too.

Error Message

Unknown error (no error details in response)

  • runId=3f86c37d-e9d2-4f04-9a6a-2d651795ad09 -> unknown error
  • runId=51ea1b12-f466-4c2c-8794-3f0471a2e297 -> unknown error
  • runId=ac855f3d-40c8-4a90-90a7-a766a109018e -> unknown error
  • runId=faf9c410-bfdf-4f5c-8dcd-7d13e0c8caca -> unknown error
  • Sessions become failed/error with no actionable reason.
  • Automatic supervisory re-pushes on the same model fail again with the same terminal unknown error. After moving affected Monica sessions to github-copilot/claude-sonnet-4.6, the same topic sessions resumed and produced assistant events (stop/toolUse/stop) without this unknown-error signature.
  1. Preserve underlying provider diagnostics (HTTP status / error code / response body fragment) instead of generic unknown.

Root Cause

With provider=azure-responses and model=gpt-5.3-codex, many runs terminate as:

Unknown error (no error details in response)

This is repeatedly observed in Telegram group sessions, but logs show the same failure pattern at the same timestamps for non-Telegram runs too.

Fix Action

Fixed

PR fix notes

PR #65254: Classify Responses unknown-no-details errors as failover timeouts

Description (problem / solution / changelog)

Summary

  • classify Unknown error (no error details in response) as a timeout-class failover signal
  • keep scope narrow to that exact OpenAI Responses transport message
  • add regression coverage for classifyFailoverReason and isFailoverErrorMessage

Why

Some Codex Azure Responses failures were ending with this exact error text and bypassing assistant failover/fallback, surfacing the raw unknown error to users instead of retrying/falling back.

Validation

  • node scripts/test-projects.mjs src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts src/agents/pi-embedded-helpers/failover-matches.test.ts

Refs: #65245

Changed files

  • .github/workflows/fork-npm-publish.yml (added, +107/-0)
  • .status.md (added, +233/-0)
  • README.md (modified, +43/-0)
  • package.json (modified, +2/-0)
  • pnpm-lock.yaml (modified, +3/-0)
  • pnpm-workspace.yaml (modified, +5/-0)
  • src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts (modified, +6/-0)
  • src/agents/pi-embedded-helpers/failover-matches.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/run.incomplete-turn.test.ts (modified, +61/-0)
  • src/agents/pi-embedded-runner/run.timeout-triggered-compaction.test.ts (modified, +86/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +8/-4)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +13/-3)
  • src/agents/pi-embedded-runner/run/incomplete-turn.ts (modified, +17/-0)
  • src/agents/pi-embedded-runner/run/preemptive-compaction.test.ts (modified, +57/-0)
  • src/agents/pi-embedded-runner/run/preemptive-compaction.ts (modified, +11/-0)
  • src/agents/pi-embedded-runner/run/types.ts (modified, +2/-0)
  • src/agents/transcript-policy.ts (modified, +4/-3)
  • src/channels/plugins/registry-loaded.ts (modified, +2/-2)
  • src/gateway/server-startup-stuck-session-replay.test.ts (added, +230/-0)
  • src/gateway/server-startup-stuck-session-replay.ts (added, +315/-0)
  • src/gateway/server.impl.ts (modified, +9/-0)
  • src/plugin-sdk/channel-runtime-context.ts (modified, +2/-1)
  • src/plugins/provider-replay-helpers.test.ts (modified, +11/-0)
  • src/plugins/provider-replay-helpers.ts (modified, +6/-1)
  • src/ui-app-settings.agents-files-refresh.test.ts (modified, +6/-0)
  • ui/src/i18n/locales/de.ts (modified, +2/-0)
  • ui/src/i18n/locales/en.ts (modified, +2/-0)
  • ui/src/i18n/locales/es.ts (modified, +2/-0)
  • ui/src/i18n/locales/pt-BR.ts (modified, +2/-0)
  • ui/src/i18n/locales/zh-CN.ts (modified, +2/-0)
  • ui/src/i18n/locales/zh-TW.ts (modified, +2/-0)
  • ui/src/styles/chat/layout.css (modified, +4/-0)
  • ui/src/styles/layout.css (modified, +102/-0)
  • ui/src/ui/app-render.helpers.ts (modified, +19/-1)
  • ui/src/ui/app-render.ts (modified, +107/-2)
  • ui/src/ui/app-settings.ts (modified, +6/-0)
  • ui/src/ui/chat-model.test-helpers.ts (modified, +3/-0)
  • ui/src/ui/controllers/sessions.test.ts (modified, +111/-0)
  • ui/src/ui/controllers/sessions.ts (modified, +92/-3)
  • ui/src/ui/navigation.browser.test.ts (modified, +18/-0)
  • ui/src/ui/views/chat.browser.test.ts (modified, +11/-0)
  • ui/src/ui/views/chat.test.ts (modified, +93/-10)
  • ui/src/ui/views/chat.ts (modified, +1/-12)
  • ui/src/ui/views/dreaming.ts (modified, +6/-0)
RAW_BUFFERClick to expand / collapse

Summary

With provider=azure-responses and model=gpt-5.3-codex, many runs terminate as:

Unknown error (no error details in response)

This is repeatedly observed in Telegram group sessions, but logs show the same failure pattern at the same timestamps for non-Telegram runs too.

Why this looks like a runtime/provider integration issue (not Telegram webhook delivery)

Telegram sends are accepted and run IDs are created:

From gateway.log:

  • runId=3f86c37d-e9d2-4f04-9a6a-2d651795ad09 (sessions.send success)
  • runId=51ea1b12-f466-4c2c-8794-3f0471a2e297 (sessions.send success)
  • runId=ac855f3d-40c8-4a90-90a7-a766a109018e (sessions.send success)
  • runId=faf9c410-bfdf-4f5c-8dcd-7d13e0c8caca (sessions.send success)

Then the same run IDs terminate in gateway.err.log with no details:

  • runId=3f86c37d-e9d2-4f04-9a6a-2d651795ad09 -> unknown error
  • runId=51ea1b12-f466-4c2c-8794-3f0471a2e297 -> unknown error
  • runId=ac855f3d-40c8-4a90-90a7-a766a109018e -> unknown error
  • runId=faf9c410-bfdf-4f5c-8dcd-7d13e0c8caca -> unknown error

Also, same window includes non-Telegram run IDs failing identically:

  • 64c83107-2361-41ab-a41e-cfd69ada9cd2
  • 22fdbfac-9deb-47bb-b919-9ae927f3c692
  • 39f11d30-d56b-43fa-ab07-ba190448b3e0
  • 3174fc84-d1d1-4360-a9fa-891c405394be

Repeated occurrence history

Older runs show same signature too (sample):

  • 0ad2e61a-a3f3-42fd-9df5-01adfd371186
  • 07ba5d6c-932b-4e5e-8e70-8c05122e0cb9
  • c13f3e99-d2f1-4dae-b6fe-1a8e0007dac5
  • 7a7aebb6-db57-463f-8905-a2696dc7338b
  • 06ab4c26-68b2-4750-8102-e7a3a6cecb08

Observed impact

  • Sessions become failed/error with no actionable reason.
  • Automatic supervisory re-pushes on the same model fail again with the same terminal unknown error.
  • Operationally this looks like dropped/stuck Telegram replies even though routing was successful.

A/B evidence (same sessions after model switch)

After moving affected Monica sessions to github-copilot/claude-sonnet-4.6, the same topic sessions resumed and produced assistant events (stop/toolUse/stop) without this unknown-error signature.

Expected behavior

  1. Preserve underlying provider diagnostics (HTTP status / error code / response body fragment) instead of generic unknown.
  2. Classify this failure as transient/retriable where safe and trigger retry/fallback automatically.
  3. Avoid terminal session failure on first occurrence of this unknown provider response.

Environment

  • OpenClaw gateway version seen in runtime: 2026.4.11-beta.1
  • Failure path: embedded run end with provider=azure-responses, model=gpt-5.3-codex
  • Workload: Telegram group topics + cron/direct sessions

extent analysis

TL;DR

The issue can be mitigated by switching to a different model, such as github-copilot/claude-sonnet-4.6, which has been shown to resolve the problem in affected sessions.

Guidance

  • Verify that the issue is specific to the azure-responses provider and gpt-5.3-codex model by checking if other models and providers are affected.
  • Check the OpenClaw gateway version and ensure it is up-to-date, as the issue is observed in version 2026.4.11-beta.1.
  • Consider implementing retry logic for transient errors, as the current implementation terminates sessions on the first occurrence of an unknown error.
  • Preserve underlying provider diagnostics, such as HTTP status codes and response bodies, to better understand and debug the issue.

Example

No code snippet is provided, as the issue is related to a specific model and provider configuration.

Notes

The issue may be specific to the gpt-5.3-codex model and azure-responses provider, as switching to a different model resolves the problem. However, the root cause of the issue is still unknown, and further investigation is needed to determine the underlying reason for the error.

Recommendation

Apply workaround by switching to a different model, such as github-copilot/claude-sonnet-4.6, as it has been shown to resolve the issue in affected sessions. This workaround can help mitigate the problem until the root cause is identified and fixed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

  1. Preserve underlying provider diagnostics (HTTP status / error code / response body fragment) instead of generic unknown.
  2. Classify this failure as transient/retriable where safe and trigger retry/fallback automatically.
  3. Avoid terminal session failure on first occurrence of this unknown provider response.
#authentication issue#prompt issue#agent setup#task chaining#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING