Desktop app: repeated "Request failed · Retrying (n/10)", sometimes needs a full restart

Summary

During ordinary Claude Code sessions (no unusual load, no large files, no special MCP tools in use), requests intermittently fail and the UI shows a retry indicator — "Request failed · Retrying (n/10) · Xs" — cycling through several attempts before either succeeding or leaving the session stuck. This has recurred repeatedly over roughly two weeks and has, at least once, left the session unresponsive until the desktop app was fully closed and reopened.

Flagging up front: I don't have access to the app's internal networking or error logs, so this is built from what I directly observed on screen and the dates/times involved — a reliability/UX report, not a diagnosed root cause.

Environment

Claude Code desktop app, Windows 11. Observed on at least three separate dates: 24-25 August 2026, 2 September 2026, and 3 September 2026, within the same ongoing project session. App version current at time of writing: 1.46388.4.0.

Evidence

Directly observed, screenshotted in-session on 24-25 Aug 2026:

⚠ Request failed · Retrying (2/10) · 35s

...recurring shortly after with the count advancing (3/10, then later 5/10 in the same episode), before the session needed to be restarted to become usable again.

The pattern recurred: badly on 2 September 2026, and twice again on 3 September 2026.

At the time of the 24-25 August episode, status.claude.com showed no currently-active incident matching the symptom — the only recent entry was an already-resolved "elevated errors" incident for different models (Opus 5, Fable 5) on a different day, which didn't match what I was experiencing (Claude Sonnet 5, on 24 Aug, not the incident's stated window).

Impact

I estimate over an hour of lost time to this specific symptom across the last month of sessions. At least one occurrence required fully closing and reopening the desktop app to restore a usable session — mid-task work was disrupted. No error detail beyond the retry counter and elapsed seconds is exposed, so there's no way to tell from inside the app whether this is a local network issue, a server-side rate limit, or something else.

Trigger

Not isolated to a specific action, file size, tool, or MCP server — happens during ordinary back-and-forth conversation, not tied to any single heavy operation identified so far.

Suggested fix

Surface the actual error/status code behind "Request failed," not just a bare retry counter, so users can tell network vs server vs rate-limit issues apart. Add a visible cancel/retry-now control rather than only a passive countdown. If this correlates with anything server-side not currently reflected on status.claude.com, worth checking whether the status page's detection threshold is missing shorter or more localized degradations.

Repro / workaround status

Not isolated to a specific reproducible trigger — recurs intermittently, roughly weekly. The only confirmed workaround when the session becomes fully stuck is closing and reopening the desktop app.