claude-code - 💡(How to fix) Fix [BUG] Claude Desktop Dispatch: messages land in pendingProcessedAcks and never clear; survives fresh install, new sessions, kill-all-sessions, manual file edits [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

On Claude Desktop for macOS, every Dispatch message sent from the mobile app is received by the Desktop client, added to processedMessageUuids in bridge-state.json, and simultaneously added to pendingProcessedAcks — where it stays indefinitely. The Desktop UI perpetually shows a "working" indicator (squiggle/spinner) because the server believes there is unacked work, while nothing is actually running locally (confirmed via ps — no child processes, no CPU attributable to the task). No reply ever arrives on the phone. There is no stop/cancel button.

The failure reproduces on a freshly installed Desktop app with a brand-new server session:

{ "<env-uuid>:<account-uuid>": { "enabled": true, "userConsented": true, "environmentId": "env_01Fc8pB3U7cqYRFyM1guYxYB", "remoteSessionId": "cse_016gxmpfAvzb8k7XjaLsoViQ", "localSessionId": "local_ditto_<env-uuid>", "processedMessageUuids": ["59b63aec-e28d-4f55-b8a3-141109f26624"], "pendingProcessedAcks": ["59b63aec-e28d-4f55-b8a3-141109f26624"] } } Every subsequent message appends to both arrays; pendingProcessedAcks never empties.

Steps to reproduce:

Sign in to Claude Desktop on Mac. Enable Dispatch in Settings. From the Claude mobile app Cowork tab, send a message to Dispatch. Message is marked "Read" on mobile. Desktop UI shows "working" indicator. No work runs locally. No reply ever comes back. Things tried that did NOT fix it:

Force-kill all Claude processes (main + helpers by PID, incl. chrome-native-host which survives Cmd+Q) — relaunch, same. Clear app caches under ~/Library/Application Support/Claude/Partitions/*/Cache — same. Sign out / sign in — same. Accept the "kill all other sessions" prompt on sign-in. remoteSessionId and environmentId regenerate server-side, but the very first message on the fresh session immediately repeats the bug. Manually empty pendingProcessedAcks by editing bridge-state.json — empties, but the next message immediately repopulates it. Delete bridge-state.json entirely so the bridge re-handshakes — same result. Full uninstall + reinstall (deleted /Applications/Claude.app and ~/Library/Application Support/Claude, reinstalled from anthropic.com) — same.

What Should Happen?

When a Dispatch message is processed, the Desktop client should successfully ack the processing to the server, clearing it from pendingProcessedAcks. The UI's "working" indicator should resolve when no work is actually running. A reply should come back to the phone. When ack delivery fails repeatedly, the client should surface a visible error rather than indefinitely showing "working." There should be a user-reachable "stop" or "clear stuck task" action.

Error Messages/Logs

Steps to Reproduce

Sign in to Claude Desktop on macOS (version 1.3883.0). Enable Dispatch in Settings. On the Claude mobile app, open the Cowork tab. Send any message to Dispatch from the phone (e.g. "hello"). Observe: the mobile UI marks the message "Read"; the Desktop UI shows a "working" indicator (spinner/squiggle). Inspect ~/Library/Application Support/Claude/bridge-state.json on the Mac. The message's UUID now appears in both processedMessageUuids and pendingProcessedAcks. Wait any length of time (minutes, hours, days). The UUID never leaves pendingProcessedAcks. The Desktop UI never stops showing "working". No reply reaches the phone. Send another message. A new UUID appears in both arrays. pendingProcessedAcks keeps growing. Reproduces on a freshly installed Desktop app and a brand-new server session (confirmed after full uninstall + reinstall, cache deletion, and "kill all other sessions" flow — remoteSessionId and environmentId both regenerate, bug persists on first message of the new session).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude Desktop 1.3883.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

macOS 15.7.1 (24G231), Apple Silicon Claude Desktop 1.3883.0 Account: Pro Network: home Wi-Fi, no proxy/firewall, other Anthropic services (CLI, claude.ai) work fine. Interpretation. Because it reproduces on a fresh install with a brand-new server session, the defect is not stale local state, zombie session IDs, corrupted install, unreaped children, or local cache. It must live in either (a) the current shipping Desktop version 1.3883.0 — broken ack endpoint, changed schema, missing auth header, etc. — or (b) a server-side handler for this account that fails to accept/acknowledge acks.

Why it matters. The UI actively misrepresents system state: "working" is displayed when nothing is working. That's worse than a visible error, because users can't trust the feature even when it appears functional, and can't debug without inspecting bridge-state.json directly.

Suggested investigation

Capture outbound traffic from Desktop when a Dispatch message arrives. Confirm the ack call is being made, reaches the server, and what response comes back. Check for recent ack-endpoint schema/auth changes that may have broken compatibility with 1.3883.0. Add a client-side ack timeout with visible error on repeated failure. Add a "clear stuck task" action for users to recover without editing local files. Related issues: #43573, #44776, #46391, #39549, #14951.