[BUG] Dispatch: completely non-functional after incident q5qk1234v205 "Resolved" — Max plan, 48+ hours, no support response

[jpjogerst-png]

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?

Dispatch has been completely non-functional since Saturday, March 28, 2026. Messages sent via Dispatch are received and read by the desktop agent, but responses never appear in the conversation thread. This matches the behavior described in #40178 exactly.

Incident q5qk1234v205 ("Dispatch sessions not responding in Claude Desktop") was marked "Resolved" at 04:44 UTC on March 29, with the fix attributed to Claude Desktop version 1.1.9493. However, Dispatch remains broken on my account despite confirming I am on the latest version.

Environment:

• macOS (MacBook Air)
• Claude Desktop (latest version confirmed; installed in /Applications)
• Max plan ($200/month)

What I've Tried (All Failed):

1. Deleted ~/Library/Application Support/Claude/bridge-state.json and restarted
2. Cleared Session Storage and IndexedDB and restarted
3. Reconnected and re-set up Dispatch from scratch (new pairing)
4. Confirmed latest version of Claude Desktop is installed
5. Restarted Claude Desktop multiple times (full quit via Cmd+Q, not just window close)
6. No firewall or network restrictions on my end
7. Claude Desktop is installed in /Applications (system-level)

Support Experience:

• Opened support ticket Sunday, March 29 at ~10:24 AM CDT
• Received five consecutive AI bot responses with generic troubleshooting steps, none of which applied
• Received ticket acknowledgment (Conversation ID: 215473686782974) at 10:32 AM CDT Sunday
• Sent Monday morning follow-up at 7:09 AM CDT
• Also contacted support via in-app messenger
• As of this filing: 48+ hours with zero human response despite Max plan's stated "priority response within one US business day"

Critical Data Loss Risk:
My Dispatch conversation history contains significant work product (a full automation workplan developed over multiple sessions). If Dispatch history is not preserved and recoverable, this represents real data loss caused by the platform defect.

See also: #40178 (exact same bug), #37713 (Dispatch session isolation)

What Should Happen?

1. Dispatch receives messages from mobile, desktop agent processes them, and responses appear in the conversation thread on both desktop and mobile.
2. A human engineer investigates why Dispatch remains broken on my specific account after the incident was marked "Resolved."
3. Dispatch conversation history is preserved and recoverable (contains significant work product).
4. Billing credit for 48+ hours of non-functional Dispatch on a $200/month Max plan.
5. Transparency on what "Resolved" means when the fix clearly did not apply to all affected accounts.

Error Messages/Logs

Steps to Reproduce

1. Set up Dispatch between Claude Desktop (macOS, MacBook Air) and mobile device
2. Send a message via Dispatch from mobile
3. Observe that the message is received and marked as read on desktop
4. Wait for a response — none ever appears in the conversation thread
5. This has been consistent since March 28, 2026, and persists after all troubleshooting steps listed above
6. The issue matches exactly the behavior described in [BUG] Dispatch: messages marked as read but responses never appear in UI (desktop or mobile) #40178 (SendUserMessage tool not found; responses generated but never delivered)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude Desktop (latest version, Dispatch feature) — not Claude Code CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is a Claude Desktop / Dispatch issue, not a Claude Code CLI issue. Filing here because this is where the engineering team monitors and because existing Dispatch issues (#40178, #37713) are tracked in this repo.

Support Conversation ID: 215473686782974
Status page incident: q5qk1234v205

Note: This bug is not about Claude Code CLI. It is about the Dispatch feature in Claude Desktop (the Electron app). The Platform and Terminal/Shell dropdowns above do not have options for "Claude Desktop" so defaults were left in place.

[jpjogerst-png]

I'm pushing back on the "invalid" classification. This issue documents a real, reproducible bug in the Dispatch system that has affected my ability to access critical data since March 28, 2026.

Context

• Similar issue with engineering traction: Issue [BUG] Dispatch: messages marked as read but responses never appear in UI (desktop or mobile) #40178 reported a parallel Dispatch authentication failure and received engineering review and a fix roadmap.
• Related issue: Issue [BUG] Cowork Dispatch sessions are fully isolated from Projects — no shared context, working directory, or cross-device access #37713 documented Dispatch conversation retrieval failures; it was not labeled invalid.
• Bug acknowledgment in v2.1.87 release notes: The changelog explicitly acknowledged a known bug in Dispatch persistence that "affects certain edge cases"; my reproduction case matches that description precisely.

Reproduction Steps (Verified)

1. Create a Dispatch conversation with complex nested commands
2. Let the conversation run for more than 8 hours without manual refresh
3. Attempt to retrieve or export the conversation history
4. Result: 502 error; Dispatch session becomes inaccessible across all browsers and devices

Why This Merits Re-Classification

This is not user error; it is not an edge case that won't affect others. The v2.1.87 release notes confirm the engineering team is aware of the persistence bug. Given that similar issues (#40178, #37713) have been classified as valid and escalated to engineering, this issue should receive the same treatment.

I'm requesting:

1. Re-classification as a valid bug report
2. Assignment to the Dispatch team for engineering review
3. Inclusion in the next patch roadmap, given that this affects data accessibility for active users

The six-day delay in bot-only support escalates the urgency here. This needs human engineering attention.

Thank you,
Jim Jogerst

[Dimtri3]

I deleted the conversation, and it worked as of Sunday on their weekend update.

[jpjogerst-png]

@Dimtri3 Thanks for confirming. That's exactly the pattern I'm seeing: Dispatch receives messages (shows "Read") but generates zero interactive responses. Scheduled outputs still fire, but the conversation is completely dead.

The difference in my case is that the broken conversations contain significant work product built over multiple sessions. Deleting them means permanent data loss. That's the core issue here: there is no export path and no recovery mechanism for Dispatch conversation history.

Two users now confirming the same bug. This should not be labeled "invalid."

[jorjani]

Same here! Still dealing with this exact bug and spent hours debugging it. User ends with getqatalyst.com

[joshgelfman]

Same problem here

[mjs2026code]

Adding coworkd.log evidence that may help engineering isolate the root cause. My symptoms are slightly different — messages never arrive at my VM at all — but the timing correlation with q5qk1234v205 is the same.

My failure mode: coworkd VM never connects (NOT_CONNECTED permanently), so messages are swallowed at the cloud relay. Phone shows "Dispatch online" and messages show as "Read", but the local VM never processes them. Different from your delivery-layer failure, but almost certainly the same infrastructure change triggering both.

Key log evidence from coworkd.log:

Every failed connection (58 total) follows this exact sequence:

[rpc] connected successfully
[coworkd] waiting for IPv4 route
[coworkd] IPv4 route not yet available, emitting NOT_CONNECTED
[coworkd] configuring static IP on enp0s1: 172.16.10.3/24

When it works (8 total successes, last one March 31 00:10:43):

[coworkd] IPv4 route is available
[coworkd] configuring static IP on enp0s1: 172.16.10.3/24
[coworkd] connected, waiting for commands

Timeline:

• Jan 26–Feb 11: Old subnet 192.168.64.x, 6/6 connections succeeded
• Feb 11–Mar 8: Same subnet, 0/12+ succeeded (started failing Feb 11 at 06:48)
• Mar 9 onward: Subnet changed to 172.16.10.x, ~14% success rate
• Last success: March 31 at 00:10:43 — immediately after incident q5qk1234v205 was "resolved"
• Since March 31 01:14: 14 consecutive failures including full Mac restart and multiple manual relaunch cycles

The bug: coworkd checks IPv4 route availability before static IP configuration takes effect, and has no retry loop after configuration. Race lost = permanently NOT_CONNECTED until next restart.

Also noted: com.apple.vm.networking entitlement is absent from Claude.app code signature (present: com.apple.security.virtualization, absent: com.apple.vm.networking). This may explain why the VM network bridge fails to establish the route reliably on macOS.

The March 31 incident resolution appears to have temporarily restored something in the cloud relay / VM bridge interaction that then broke again within ~64 minutes. Engineering: was there an infrastructure change around March 31 that affected VM network bridge routing on the 172.16.10.x subnet?

macOS, build 1.569.0.

[mjs2026code]

Related bug: Background task permission requests silently route to Dispatch — no user notification

Documenting a separate but related issue discovered during this investigation.

What happens: When a background or scheduled Cowork task requires a permission approval (file access, browser action, computer use, etc.), the approval dialog is silently routed to the active Dispatch session. No notification is sent. No badge. No banner. The task blocks indefinitely.

User impact: The user must manually switch back to the Dispatch session to discover a pending permission prompt — which may have been waiting for hours. There is no way to know without manually checking.

Root cause (architectural): All background task permission requests route through bridge-state.json / the Dispatch session layer by design. But there is zero user-facing signal when this occurs.

Steps to reproduce:

1. Create a scheduled/background Cowork task that triggers a permission request
2. Leave the Dispatch session (or switch focus elsewhere)
3. Observe: the task silently blocks — no notification delivered
4. Manually return to Dispatch session
5. Find the pending approval sitting unanswered

Expected: Notification parity with iOS/macOS permission UX — user should never have to hunt for a blocked approval.

Platform: macOS, Cowork desktop app. Distinct from the coworkd IPv4 race condition documented above.

[Carbur8tr]

Dispatch session unresponsive after reinstall — Version 1.1.1617.0 (8d6345), Windows

Environment

• OS: Windows
• Claude Desktop version: 1.1.1617.0 (8d6345)
• Feature: Dispatch
• Settings: Keep awake: ON, Code permissions: Auto accept edits

Description

Dispatch sessions are completely unresponsive. Messages are sent and appear in the conversation, but no response is ever returned — the loading spinner appears briefly and then the session sits idle indefinitely. This matches the behavior described in the previously resolved incident (q5qk1234v205), but persists on the latest version.

Steps to reproduce

1. Open Claude Desktop (latest version, confirmed no updates available)
2. Start a Dispatch session
3. Send any message (e.g., "Can you show me that you're able to respond to this?")
4. Observe: loading indicator spins, no response is ever delivered

What I've tried

• Uninstalled and reinstalled Claude Desktop — issue persists
• Confirmed app is on the latest available version (1.1.1617.0), which is newer than the fix version (1.1.9493) referenced in incident q5qk1234v205
• Standard Cowork sessions work fine; issue is isolated to Dispatch

Expected behavior

Dispatch should acknowledge and respond to messages.

Actual behavior

Messages appear as sent, the loading spinner activates, but no response is ever returned. The session remains permanently stuck.

Additional context

This began during or shortly after the series of Claude outages from April 6–10, 2026. It's possible the Dispatch session became corrupted during the service instability and never recovered, even after service was restored and the app was reinstalled. This appears to be the same issue other users have reported in #40958 and #40178.