[Bug]: Provider error card offers no visible recovery action or guidance

[jenewland1999]

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to investigate the problem. A deterministic way to trigger the original HTTP 401 has not been established.

Area

apps/web — conversation error UI, observed in the desktop app.

Steps to reproduce

Observed incident sequence; not a deterministic reproduction of the authentication failure:

1. Run a task in a T3 Code thread.
2. Encounter a provider failure displaying Provider request failed with HTTP 401.
3. Inspect the provider error card in the conversation.
4. With no visible retry action beside the error, send a new message containing try again.
5. A subsequent response appears beneath that message, with a Worked for 43s row.

The captured full-window screenshot (upload pending) shows the error, the manually sent try again message, a subsequent response, and the empty composer. Unrelated content has been obscured. This report concerns recovery discoverability at the point of failure, not the underlying cause of the HTTP 401.

Expected behavior

The error should explain how to recover and continue the interrupted task. A Retry/Continue action beside the error, or guidance pointing to an existing recovery control, would make the next step clear.

For HTTP 401, explain that authentication may need attention and direct the user to the relevant provider settings or sign-in workflow before retrying. An automatic retry loop for authentication failures is not requested.

The documentation describes Resume in an empty composer for stopped runs and usage limits. If that is also the supported recovery path for this failure, the error should make that connection clear. Maintainers can determine whether this needs a UI fix, clearer guidance, or an Ideas discussion for a new control.

Actual behavior

The error card displays:

Provider error
Provider request failed with HTTP 401

There is no visible Retry/Continue action or recovery guidance in the error card. It is not clear from the error how to continue after addressing the underlying problem.

The screenshot shows that sending try again was followed by another response. In this captured state, the empty composer shows an upward-arrow send icon rather than a labelled Resume action. Because the screenshot was taken after the follow-up response, it does not establish what the composer displayed immediately after the failure.

Impact

Minor bug or occasional failure.

Interrupts work and makes recovery frustrating because the user must work out the next step.

Version or commit

Current installed desktop app and connected server, verified on 3 November 2026: 0.1.7-nightly.20261103.4119.

The version at the exact time of the screenshot has not been independently confirmed.

Environment

• Client: T3 Code (Nightly) desktop app.
• Desktop app version: 0.1.7-nightly.20261103.4119.
• Connected server version: 0.1.7-nightly.20261103.4119.
• OS: macOS 26.6.2, build 25G83.
• Architecture: Apple Silicon (arm64).
• Model/reasoning label visible in the screenshot: 6.1 Sol Medium.
• Provider for the failed request: not confirmed. The screenshot's model selector does not establish the provider or whether the selection changed after the failed request.

These are the current environment details, not a reconstruction of the original failure's complete configuration.

Logs or stack traces

Provider request failed with HTTP 401

No correlated stack trace or confirmed authentication root cause is included.

Screenshots, recordings, or supporting files

A redacted full-window screenshot was reviewed while preparing this report. It shows the HTTP 401 error, the manually sent try again message, a subsequent response, and the composer labelled 6.1 Sol Medium.

Screenshot upload is pending; the submission tool could not attach it. The observations above describe the captured state, not a fresh reproduction.

Workaround

Send a new message such as try again. The supplied screenshot shows a subsequent response after this message, so it provides evidence of continuation in this instance. It does not establish that the original task completed successfully or that this workaround works for all HTTP 401 failures. No sign-in step is shown, and the cause of the original failure remains unknown.

Related reports

• [Bug]: Auto Retry after Provider Error: Selected model is at capacity #26924 — automatic retries for Codex capacity errors; closed as fixed. Different failure and recovery mechanism.
• [Bug]: Claude auth failure renders as plain result text with no re-login affordance #7878 — missing recovery guidance for Claude authentication failures; closed. Similar presentation concern, provider-specific.
• [Bug]: Codex turn hangs silently during provider 429 retries; session left wedged in systemError until the next manual message #17503 — Codex HTTP 429 recovery requiring another message; open. Different error and stalled-session behavior.