[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 stringServer is temporarily limiting requests (not your usage limit) · Rate limitedwith 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 afterCycleHealthmarks a cycle asunhealthy (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)
- Open Claude Desktop and a local Claude Code session with conversation history already present.
- Submit a prompt. The API starts streaming, so
hadFirstResponsebecomestrue. - Mid-response, the server returns the shared-capacity rate-limit error.
- 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.
- 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:
- Keep the input field enabled so the user can type a fresh message and retry.
- Show a visible error banner (e.g. "Server is busy, try again") with a Retry action for the last turn.
- Clear the
unhealthy cyclestate once the user dismisses the error or submits a new turn — or at least when the user switches to a different session. - 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.
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate of any of those three; the bot flagged a different set than the one I preemptively addressed in the body, so handling these explicitly:
MaxFileReadTokenExceededError— file size limit, and PNG decode errors further down the log), not a server shared-capacity rate-limit. Different trigger, different failure mode.API Error: Prompt is too long— a context-size error, not a server rate-limit — and their state persists through a full PC reboot, while mine recovers with just an app restart. Different error trigger, different recovery path, and arguably a different underlying layer (theirs looks like server-side account state corruption; mine is a local UI state-machine defect). If they happen to share a root cause, fixing this one would be a subset of fixing theirs — but filing them separately lets each be verified on its own repro.The specific failure mode here — shared-capacity throttle (
not your usage limit) →unhealthy cycle (reason=api_error)→ input locked across all sessions → recovered byCmd+Q+ relaunch — doesn't appear in any of those three reports. See issue body for log evidence.Update — appears fixed in Claude Desktop 1.4758.0 / CCD 2.1.119
The same rate-limit error recurred today on the upgraded version (originally filed against 1.3561.0 / CCD 2.1.111), and this time on two sessions simultaneously:
Same trigger, same
unhealthy cycle (reason=api_error)state transition — but the input field stayed usable this time. Sent a message to a different focused session 4 seconds after the error:Then switched into both errored sessions and sent messages to them too:
Both sessions returned to a healthy state shortly after:
8
sendMessagecalls between 09:03 and 12:44 with nobeforeQuitin that window — i.e. no app restart was required at any point.Whatever was making the input field stick on 1.3561.0 / 2.1.111 appears to have been addressed in 1.4758.0 / 2.1.119. Fine to close from my end. Posting the confirmation here in case there's an associated changelog entry that should be linked to this issue for searchability.
Confirming this is resolved on my end. Five days post-upgrade and the underlying rate-limit trigger has still fired a few times (latest: 2026-05-02 00:08:34 —
Server is temporarily limiting requests), but in every recurrence the input field stayed usable and the affected session resumed normally on retry. The 1.4758.0 / CCD 2.1.119 fix held.Closing as fixed. Thanks.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.