[Bug] Prompt input locked indefinitely after "Server is temporarily limiting requests" rate-limit error — only full app restart recovers

### Not a duplicate — preemptive disambiguation This issue shares the error string Server is temporarily limiting requests (not your usage limit) · Rate limited with a couple of other reports, but the symptom, scope, and fix surface are all different. | Candidate | Why it's not the same | |---|---| | #50841 (feature request) | Asks for server-side auto-retry with backoff. That would reduce frequency of this bug but would not fix the underlying UI state-machine defect. Even if auto-retry is never added, this bug should still be fixed — a surfaced error should not silently lock the input field. | | #50908 (quota accounting confusion) | That reporter was still able to enter prompts ("With those two prompts I was able to enter simple questions…"). My bug is that I cannot enter any prompt at all — the input field is locked. Different symptom. | | #51649 (webview crash on session switch) | Different bug I filed from the same machine/setup. Different trigger (session switch, not rate-limit), different symptom (webview killed + app restart vs. input locked). Cross-referenced here only for transparency — not a duplicate. | This report is specifically about a UI state-machine defect: the prompt input field becomes unresponsive after CycleHealth marks a cycle as unhealthy (reason=api_error), and no in-app action — clicking, typing, switching sessions — restores it. Only a full app restart does. I have not found another issue describing that specific failure mode.

Environment

• Claude Desktop: 1.3561.0
• CCD: 2.1.111
• Claude Code CLI binary: 2.1.111 (used internally by CCD)
• macOS: 26.3 (25D125), Apple Silicon (Mac17,2, 24 GB RAM, arm64)
• Node (inside Electron): 24.14.0
• orgId (from logs): 138437b2-fcf0-4696-a33a-17e0410d8ba4

Summary

When the Anthropic API returns the shared-capacity throttle error (Server is temporarily limiting requests (not your usage limit) · Rate limited) mid-response, the session transitions to unhealthy cycle / reason=api_error and the prompt input field becomes completely unresponsive. Keystrokes don't register, the send button doesn't work, and there is no error banner, retry button, or recovery UI. Switching to another session in the sidebar does not recover it. The only way to restore a usable app is to fully quit Claude Desktop (Cmd+Q / force-quit) and relaunch it.

This is not a usage-based rate limit — the error explicitly says (not your usage limit). It's a transient shared-capacity throttle.

Steps to reproduce (probabilistic — depends on Anthropic server load)

1. Open Claude Desktop and a local Claude Code session with conversation history already present.
2. Submit a prompt. The API starts streaming, so hadFirstResponse becomes true.
3. Mid-response, the server returns the shared-capacity rate-limit error.
4. Observe:

• The response stops.
• The session is marked as unhealthy cycle (reason=api_error).
• The prompt input field stops accepting typing.
• No error banner, no "Retry" affordance, no indication that input is disabled.

1. Try every in-app recovery I attempted — clicking in the field, clicking the send button, switching to a different session in the sidebar. None re-enable the input field.

Only fully quitting Claude Desktop (Cmd+Q) and relaunching restored a usable input field.

Recovery

| Attempted recovery | Result |
|---|---|
| Clicking in the input field | No effect — keystrokes don't register |
| Switching to a different session in the sidebar | No effect — the other session's input is also unresponsive |
| Passive time (I stepped away from the machine for ~4h; wasn't actively testing this, but the state was unchanged when I returned) | Did not self-recover — input still locked |
| Full app quit and relaunch (Cmd+Q) | Works — input usable again |

The recovery path is entirely out-of-app. There is no in-app action that restores usability.

Log evidence (from ~/Library/Logs/Claude/main.log)

The error and subsequent state change:

2026-04-23 08:12:20 [warn] [CCD CycleHealth] local_584b79ed-… api_error (success):
                             API Error: Server is temporarily limiting requests
                             (not your usage limit) · Rate limited
2026-04-23 08:12:20 [info] [CCD CycleHealth] unhealthy cycle for local_584b79ed-…
                             (93s, hadFirstResponse=true, reason=api_error)

Followed by 4h16m of zero session activity — only background housekeeping (hourly update checks, growthbook refresh, blocklist fetch, EventLogging flushes). I was AFK during this window, not actively testing recovery. When I returned at 12:28, I tried switching to another session (setFocusedSession at 12:29:01) — that didn't restore input either, so I force-quit the app at 12:30:44. That worked.

The gap is still useful signal: the stuck state persisted across 4+ hours with no self-recovery, so "just wait" isn't a recovery path.

2026-04-23 08:12:20  [unhealthy cycle event above]
2026-04-23 08:26:14  [updater] Checking for updates             ← hourly housekeeping only
2026-04-23 09:26:14  [updater] Checking for updates
2026-04-23 10:26:14  [updater] Checking for updates
2026-04-23 11:26:14  [updater] Checking for updates
2026-04-23 12:26:14  [updater] Checking for updates
...
2026-04-23 12:28:23  [SkillsPlugin] Window focused — polling now
                        (last poll was 15475148ms ago)          ← 4.3h since last focus event
2026-04-23 12:29:01  [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-04-23 12:29:01  [CCD] Warming session local_3840db9e-…     ← switched to another session; did NOT recover
2026-04-23 12:30:44  beforeQuit: handler fired, going down      ← full app quit (only thing that worked)

The last poll was 15475148ms ago (≈4.3 hours) confirms no focus/interaction events reached the renderer during the stuck window. The session switch at 12:29:01 followed by a quit 90 seconds later at 12:30:44 confirms that switching sessions did not restore input.

Expected behavior

A transient shared-capacity throttle is retryable. The client should, at minimum:

1. Keep the input field enabled so the user can type a fresh message and retry.
2. Show a visible error banner (e.g. "Server is busy, try again") with a Retry action for the last turn.
3. Clear the unhealthy cycle state once the user dismisses the error or submits a new turn — or at least when the user switches to a different session.
4. Ideally, implement client-side auto-retry with exponential backoff for the shared-capacity class of errors (see #50841).

Actual behavior

• Input is silently locked.
• No banner, no error surface, no Retry button.
• Switching sessions doesn't reset the lock — a different session's input is also unusable.
• Only recovery is force-quitting the app.

Why this matters

• Hit on the first prompt of my morning — no workaround possible because you can't do anything until after you've already triggered it.
• The stuck state persisted across a 4+ hour gap with no self-recovery, confirming a full app restart is required — there's no in-app or passive recovery path.
• The error message itself says (not your usage limit) — the user knows they should just retry, but the UI offers no path to do so.
• The need to fully restart the app is a significant UX regression from behavior where errors surface recoverably.

Additional notes

• My setup during the incident: 2 concurrent local Claude Code sessions on a git worktree (.claude/worktrees/sleepy-shannon-e453e3), 6 MCP servers (Claude in Chrome, mcp-registry, Claude Preview, ccd_session, ccd_directory, scheduled-tasks), 3 plugins (skills:1, local:2).
• Session state at time of error: hadFirstResponse=true, cycle had been running 93 seconds — the error interrupted an in-progress response.
• Happy to share the raw log snippet or more timestamps on request.