[BUG] Dispatch permanently stuck — never resets to QR code pairing state, "Can't reach your desktop" / "Asleep" on mobile (Windows 11)

Update following additional troubleshooting:
After filing this report I attempted a completely clean re-pair from scratch:

Disabled NordVPN entirely
Logged out of Claude on mobile
Cleared background tasks on desktop (via the three-dot menu), which revealed the "Pair your phone" onboarding screen — notably, "Delete conversation" from the same menu did NOT reveal this screen
Completed the full pairing flow: scanned a fresh QR code with the iPhone camera, was redirected to a "Take Claude on the Go" page in the mobile browser, opened the iOS app from there
Logged back into Claude on mobile
Tapped Dispatch in the mobile sidebar

Result: immediately shows "Asleep" at the top and "Can't reach your desktop. Check that your computer is online and desktop app is open." at the bottom. Send button non-functional. Identical to pre-pairing state.
This rules out VPN interference, stale pairing state, and any local configuration issue as causes. A brand new pairing fails instantly and consistently. The connection never reaches "Online" status even for a moment.

Cowork Dispatch stuck on "Asleep" — desktop healthy, phone can't reach it (Windows 11)

Summary: In Cowork Dispatch, my iPhone shows my desktop as "Asleep" and won't let me send tasks — even though the Windows desktop is awake, online, signed in, and the Claude Desktop app is open with Dispatch configured correctly. This is a regression: Dispatch worked reliably from install in April 2026 until ~May 2026, when it began showing "Asleep." It looks like the server-side relay / pairing-sync issue already reported on Windows.

Plan: Claude Max

Environment

• Desktop: Windows 11, Claude Desktop app (latest version), Cowork → Dispatch (Beta)
• Mobile: iPhone, Claude app (latest version), iOS (latest version)
• Same Anthropic account signed in on both devices
• Both devices online; Windows sleep setting is "Never"

What's happening

• After initial install in April 2026, Dispatch worked successfully between the desktop PC and the iPhone.
• Starting around May 2026, the iPhone began showing the desktop as "Asleep" / "Can't reach your desktop," and the Send button will not activate.
• The desktop is clearly awake and working — I'm actively using Cowork on it at the same time.

Desktop Dispatch panel state (verified)

• Keep awake: ON
• Computer use: enabled
• Panel shows the normal Settings view, not the QR / "Get started" setup screen — i.e., the desktop believes it is paired and ready
• No error or "disconnected" message on the desktop side

Expected behavior

The phone should show the desktop as online/available and allow tasks to be sent.

Troubleshooting already done

• Confirmed Keep awake is ON and the desktop is awake and online
• Confirmed both the desktop and mobile apps are on the latest version
• Force-quit and reopened the Claude app on the iPhone
• Fully quit and reopened the Claude Desktop app
• Reinstalled Claude on both the iPhone and the Windows desktop
• Turned off VPNs on both devices
• Result: still stuck on "Asleep" — none of the above changed the behavior

Related reports (appear to be the same issue)

GitHub anthropics/claude-code issues #67682, #44225, #51389 — all describe Dispatch stuck on "Asleep" on Windows despite a healthy desktop, suspected to be a server-side relay / pairing state that local troubleshooting cannot clear. (Note: those report it never working; in my case it worked first and then regressed.)

Request

Please reset or refresh the Dispatch pairing relay — the pairing state appears to be held server-side and is not clearing with local steps — or advise on next steps.

• Windows, Max plan, Dispatch never successfully paired.
• Desktop Cowork, Code, Chat all function. Dispatch panel renders and computer use registers.
• Reproduced across two independently set-up desktops. Second machine freshly configured, computer use registered, panel healthy, phone still “Asleep / can’t reach desktop.”
• Mobile app deleted and reinstalled. No change.
• Request: server-side investigation of why the account never establishes a mobile-to-desktop Dispatch binding, and a pairing-state reset.

Same symptom on macOS, filed as #86031.

One difference that may be diagnostically useful: in my case pairing was never established at all. The Dispatch panel has never rendered the QR code or the "Get Started" screen — not once, on a Pro account. So this isn't a working pairing that went stale; there is no prior paired state to have gone stale.

Everything else matches this thread: the panel shows only Settings, "Delete conversation" has no effect, deleting ~/.claude/bridge-state.json has no effect, and a full uninstall/reinstall of Claude Desktop has no effect either.

If the server-side relay record is created lazily on first pairing, a never-paired account failing this way might point to a provisioning path rather than a stale-state path — possibly two bugs surfacing identically. Either way the client has no route back to the pairing screen, so a server-side reset seems to be the only remedy.

Update — more specific symptom pattern

Following up on this issue (and the parent #67303). I want to add a more precise detail about the failure mode that might help narrow down the root cause.

The pairing/relay channel is not uniformly broken — it's asymmetric:

Desktop → iOS (pull): Works normally. I can start a Cowork task on my Windows desktop and pick it up, view it, and even send updates to it from my iOS Claude app.
iOS → Desktop (push/initiate): Fails. Attempting to start a new Dispatch task from iOS while the desktop app is open, online, and awake results in the mobile app showing "Asleep," and the task never reaches the desktop.

This suggests the underlying connection/registration between the two devices is at least partially live (since the pull direction works), but whatever mechanism is supposed to wake or notify the desktop app to accept a new incoming task from mobile is not functioning. This may be a more specific manifestation of the same server-side pairing problem already described in #67303, but the direction-specific nature of the failure seemed worth documenting separately in case it points to a distinct part of the relay logic.

Environment is unchanged from my original report: Windows 11, latest Claude Desktop, latest iOS Claude app, same Pro account on both devices.