[BUG] Claude Desktop (Code tab, macOS) — new messages hang indefinitely at "Sending...", never transmit

Status Fixed / completed

Maintainer reply None cached

Activity 4 comments · opened Sep 11, 2026 · closed Sep 24, 2026

Environment

App: Claude Desktop (macOS)
Version: v1.24012.9 (update pending — auto-updater itself is also broken, see related bug below)

Symptom

Typing a new message into the Code tab chat input and sending it results in a status line reading ✳ Sending... with a live, correctly-incrementing timer (e.g. 1m14s → 1m18s → 1m25s → 1m34s and climbing).

The message never actually transmits. No response begins streaming, no error is shown, and the timer never resolves — it just keeps counting indefinitely if left alone.

This has been reproduced across multiple different projects and multiple different sessions, both long-running and freshly started — session length/history size does not appear to be a factor.

Key diagnostic detail

Slash commands (/compact, /doctor) complete normally and quickly.
Regular chat messages consistently hang at "Sending..." and never complete.
This split suggests the failure is specific to whatever code path initiates a new standard conversational turn, not a general connectivity/server issue — a broken network or server would be expected to affect both equally.

Workarounds found so far

Interrupting and sending a follow-up message sometimes revives it.
Fully quitting and relaunching the app sometimes resolves it for the next send.
Neither is reliable — the hang recurs on subsequent messages.

Related issue possibly compounding this

The in-app auto-updater ("Relaunch to update") repeatedly prompts for an administrator name/password to "add a new helper tool," but never completes the install even after credentials are entered correctly — consistent with a known Sparkle-framework bug (errAuthorizationCanceled, OSStatus -60006) where the authorization handshake with the privileged helper tool fails/cancels itself. This may be preventing the update to a newer build that could fix the "Sending..." hang.

Related reports

Several other reports of the same/similar symptom exist but appear closed as duplicates without a linked canonical issue, so filing fresh with full repro details:

#54297 (Windows, Cowork/agent mode)
#35025 (macOS, every message hangs)

View original on GitHub ↗

3 Comments

tytspoxai-ops · 1 month ago

Same symptom here, on a different (newer) build — adding data in case it helps narrow this down.

Environment

macOS 26.6.2 (Apple Silicon, 16 GB)
Claude Desktop 1.52386.3 (auto-updated from 1.49585.0 on 2026-09-12)
Bundled Claude Code runtime changed with that update: 2.1.260 → 2.1.266

Before vs. after the update (from ~/Library/Logs/Claude/main.log, CCD CycleHealth lines)

| | Desktop / runtime | messages sent | healthy cycles | unhealthy cycles |
|---|---|---|---|---|
| before (~8.5 h) | 1.49585.0 / 2.1.260 | 69 | 92 | 0 |
| after (~35 h) | 1.52386.3 / 2.1.266 | 125 | 184 | 10 (7 with hadFirstResponse=false) |

The 7 no-response hangs lasted 41 s, 337 s, 429 s, 469 s, 541 s, 794 s, 798 s — each ended only because I quit the app (reason=app_quit). Small pre-update sample, so treat the "0" with some caution.

What a hang looks like in the log (typical case, typed directly into the composer of a session that had finished its previous turn ~4 min earlier and was idle):

11:59:04 [info] LocalSessions.sendMessage: ... messageLength=86 ...
11:59:04 [info] Sending message to session local_…
         (nothing at all for this session for 5.5 minutes — no start-timing, no error, no process exit)
12:04:42 [info] [CCD CycleHealth] unhealthy cycle for local_… (337s, hadFirstResponse=false, reason=app_quit)

After relaunching, the same session warms up in ~250 ms and works normally until the next hang.

Observations

The bundled Claude Code process does not exit or log an error during the hang — the turn simply never starts. This looks different from the older "process exited with code 1" reports (#37641, #37887) and closer to #86088 (turn never starts, hadFirstResponse=false, silent), except here it's macOS and the messages are typed directly by the user, not cross-session deliveries.
All MCP servers were reported connected (init_mcp=connected:19/pending:0/failed:0) for the affected sessions.
The first hang appeared ~20 minutes after the 1.52386.3 update was installed.
Workaround: quit and relaunch, then Stop + resend. Stopping without relaunching is unreliable.

Happy to provide more log excerpts if useful.

ygb4520-cmd · 26 days ago

Still reproducing on the latest available build as of 2026-09-19 — Claude Desktop 2.2553.1, bundled Claude Code runtime 2.1.275 (both newer than every version discussed above), so whatever changed between the versions mentioned earlier hasn't resolved this.

Most recent occurrence, from ~/Library/Logs/Claude/main.log:

23:02:46 [info] Starting local session local_73799b99-80db-481d-a14b-902fd441600f
...
23:18:59 [warn] [CCD] Session local_73799b99-80db-481d-a14b-902fd441600f timed out after 972s of inactivity (hadFirstResponse=false, last_message_type=command_lifecycle, last_tool_name=none, seconds_since_stderr=never, prompt_lifecycle=started, host_requests_in_flight=0, host_requests_before_prompt=1, clock_gap_ms_max=none, ms_since_clock_gap=none)
23:18:59 [info] [CCD CycleHealth] unhealthy cycle for local_73799b99-80db-481d-a14b-902fd441600f (973s, hadFirstResponse=false, reason=no_response)

~16 minutes with zero activity before it self-timed-out — no tool calls, no error, turn just never starts. Same shape as the original report and the comment above.

Also seeing it the day before (2026-09-18), three sessions going unhealthy in the same second with two different reason codes:

08:41:45 [info] [CCD CycleHealth] unhealthy cycle for local_b6607560-53f9-49fc-acbc-06c59c2a0e9b (1546s, hadFirstResponse=true, reason=incomplete_response)
08:41:45 [info] [CCD CycleHealth] unhealthy cycle for local_ca35c197-f5a9-4285-90d7-fae849c79869 (1496s, hadFirstResponse=false, reason=no_response)
08:41:45 [info] [CCD CycleHealth] unhealthy cycle for local_e72a31d8-ed94-47d0-81de-c048b6a1e8e6 (1496s, hadFirstResponse=true, reason=incomplete_response)

Doesn't look isolated to one code path (no_response vs incomplete_response, both hadFirstResponse states represented). Environment: macOS, same machine as before.

ygb4520-cmd · 25 days ago

Small update: today (2026-09-20) is looking better — 2 sessions so far, both healthy cycles, 0 unhealthy, versus the string of no_response/incomplete_response hangs through last night. Same machine, same Desktop 2.2553.1 / CCD 2.1.275 build as the addendum above, no app update in between.

Not enough data yet to say it's resolved (small sample), but flagging in case it's a genuine improvement rather than a fluke — will keep watching.

Showing cached comments. Read the full discussion on GitHub ↗