Skip to content

[Bug]: Generic Telegram failure suggests /new for non-user-recoverable model/config errors #104490

Description

@smoe-bot

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When an embedded Codex agent fails before replying because of a model/account configuration error, Telegram shows a generic recovery message suggesting retry or /new, even though the failure is not user-recoverable and requires administrator attention.

Steps to reproduce

  1. Run an OpenClaw Telegram direct session using the Codex runtime with an unsupported model/account combination.
  2. Send a Telegram message that triggers the embedded agent.
  3. Observe the Telegram fallback message.
  4. Check OpenClaw logs for the underlying model/account error.

Observed case:

rawError={"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account."}}
2026-07-11T14:45:15.321+02:00 Embedded agent failed before reply: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account."}}
2026-07-11T14:45:15.569+02:00 [telegram] outbound send ok accountId=default chatId=<redacted> messageId=<redacted> operation=sendMessage deliveryKind=text chunkCount=1

Expected behavior

For failures classified as non-user-recoverable system/configuration/provider/account errors, OpenClaw should not suggest retry or /new as the primary recovery path.

A safer user-facing message would be along the lines of:

The agent failed because of a system configuration problem. An OpenClaw administrator has been notified.

The instance administrator should receive a sanitized diagnostic containing the error class, sanitized cause, affected lane/session, timestamp, and a pointer to the logs. For trusted owner/admin recipients, the message may include a concise diagnostic such as:

Model/account mismatch: gpt-5.5-pro is not supported for Codex with this account.

Raw stack traces, secrets, full request payloads, environment dumps, and unredacted logs should not be forwarded.

Actual behavior

Telegram displayed:

Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

The suggested actions were misleading in this case. Retrying or starting a fresh session cannot resolve an unsupported model/account configuration. The actionable cause was only visible after inspecting logs.

OpenClaw version

OpenClaw 2026.7.1-beta.5 (b6387af)

Operating system

Linux GENtle 7.1.3+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.1.3-1 (2026-07-04) x86_64 GNU/Linux

Install method

npm global ([email protected])

Model

gpt-5.5-pro via Codex, from the observed error message

Provider / routing chain

Telegram direct -> OpenClaw embedded agent -> Codex runtime -> ChatGPT account

Additional provider/model setup details

The failure occurred in a setup where OpenClaw can contact similar model/provider services through multiple surfaces, lanes, and running sessions. This increases the chance of stale or incompatible model settings when new models become available.

A relevant operational detail is that models set ... does not immediately affect already running sessions. Therefore, an administrator may believe the model configuration was corrected while an existing Telegram direct session still uses the incompatible effective model until that path is exercised.

Logs

rawError={"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account."}}
2026-07-11T14:45:15.319+02:00 [diagnostic] lane task error: lane=main durationMs=1908 error="Error: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account."}}"
2026-07-11T14:45:15.320+02:00 [diagnostic] lane task error: lane=session:agent:main:telegram:direct:<redacted> durationMs=1910 error="Error: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account."}}"
2026-07-11T14:45:15.321+02:00 Embedded agent failed before reply: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account."}}
2026-07-11T14:45:15.569+02:00 [telegram] outbound send ok accountId=default chatId=<redacted> messageId=<redacted> operation=sendMessage deliveryKind=text chunkCount=1

Screenshots, recordings, and evidence

Telegram showed:

Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

The logs above show the underlying non-user-recoverable model/account error.

Impact and severity

Affected: Telegram direct users and OpenClaw instance administrators.

Severity: Moderate. The agent turn fails, and the visible recovery instruction is misleading.

Frequency: Observed once for this specific model/account mismatch.

Consequence: The user is asked to try /new even though the problem requires administrator action. The administrator may not become aware unless they manually inspect logs.

Additional information

Related but distinct from #87299 and #93251.

#87299 concerns spurious generic "Something went wrong" messages in Telegram direct sessions, including after a successful Codex run. #93251 concerns raw internal tool/runtime failure details leaking into Telegram. This issue sits between those two: the fallback message is sanitized, but the error is misclassified and the suggested recovery action is wrong.

The desired behavior is not to expose raw failure details to ordinary users. Instead, OpenClaw should classify non-user-recoverable system/configuration/provider/account failures separately, avoid suggesting /new, and notify the instance administrator with sanitized diagnostics.

I can prepare a patch for this classification/message-routing behavior if maintainers agree with the proposed direction.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions