Dispatch main conversation permanently offline despite working Cowork tasks

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40587
2. https://github.com/anthropics/claude-code/issues/40281
3. https://github.com/anthropics/claude-code/issues/40247

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of the linked issues. Those describe scenarios where Dispatch connects but fails to deliver/render responses (messages marked as read but no output).

My issue is different: the desktop reports itself as offline — both from the mobile client ("Can't reach your desktop") and from the desktop's own Dispatch main conversation ("Desktop appears offline. Will run when it reconnects."). The connection is never established in the first place.

Notably, individual Cowork tasks still work fine on the same machine, confirming the underlying system is functional. The issue is isolated to the main Dispatch conversation thread/session being permanently stuck in an offline state, which no amount of local troubleshooting (restart, reinstall bridge state, full re-login on both devices, Dispatch toggle) can resolve.

This points to a server-side session state issue specific to the main Dispatch conversation, not a client-side rendering or message delivery problem.

I am also experiencing this exact issue and I can't fix it I've done everything I can think of

same thing here!

I changed computer and setup Dispatch on a new desktop but from my phone it still appears offline

just happen after upgrading to latest Claude 1.1617.0 (8d6345) 2026-04-09T16:10:15.000Z

SOLVED! just happened to me 4 hours ago. after a lot of craziness, my solution: on desktop app, click three lines on the upper left corner , then help/troubleshooting/reset app data and that did it for me.

Update: Resolved — minimal fix identified

The issue was caused by a corrupted bridge session in local-agent-mode-sessions/, likely from the April 9th server incidents.

Fix that worked:

1. Quit Claude Desktop
2. Delete only the bridge-related data:

rm -rf ~/Library/Application\ Support/Claude/local-agent-mode-sessions/
rm ~/Library/Application\ Support/Claude/bridge-state.json

1. Reopen Claude Desktop

This preserves all conversation history, context, and settings — only the bridge relay session is reset. No need to delete claude-code-sessions/ or do a full app data reset.

For others experiencing this: Back up ~/Library/Application Support/Claude/ first, then delete only those two paths. Your Dispatch context will survive.

On Windows, quitting claude desktop, deleting the bridge-state.json file, and then re-opening Claude desktop was enough to fix for me - I think this re establishes the session handshake

Same issue on Windows

Experiencing the same problem on Windows.

Environment

• Claude Desktop version: 1.2278.0.0 (MSIX / Windows Store)
• OS: Windows 11 Home 10.0.26200
• Plan: Max
• Claude Code version: 2.1.107

Symptom

• Claude Desktop entered read-only state at around 17:21 JST (08:21 UTC) on April 14, 2026 and has not recovered.
• Restarting the app, clearing cache/session storage/lockfile, and full process kill + relaunch did not resolve it.
• Claude Code CLI continues to work normally — the issue is isolated to the Desktop app's Dispatch/connection.

What I've Tried (none worked)

• Killed all Claude Desktop processes and relaunched
• Cleared Session Storage, Cache, GPUCache, and lockfile
• Verified bridge-state.json exists with valid session data
• Confirmed no local sleep/power/network issues

This matches the server-side relay issue described in this thread. Adding a data point that it also affects Windows users, not just macOS.

The dispatch session with the Claude Application is also not working for me it says the Desktop appears Offline, Have tried all workarounds including ``rm ~/.config/Claude/bridge-state.json`` and restarting the desktop app to no luck.

The dispatch session with the Claude Application is also not working for me it says the Desktop appears Offline, Have tried all workarounds including rm ~/.config/Claude/bridge-state.json and restarting the desktop app to no luck.

Same problem here on Windows 10 since this morning, dispatch is constantly on "desktop is offline" both on mobile or in the desktop client.

Plan: Pro
Claude Desktop Version 1.2773.0 (884b37)
Windows 10 Pro, version 22H2, build 19045.6466

Yep. Same. Mac OS running latest version. Was working fine until this morning's big outage. When the systems came back, Dispatch didn't return with everything else. At least in my experience.

Claude Desktop version: 1.2773.0

More details on troublshooting:

Dispatch stopped working after the April 15, 2026 platform outage (incident resolved at 17:42 UTC). Mobile client shows "Can't reach your desktop" and desktop Dispatch panel shows "Desktop appears offline." Cowork tasks function normally otherwise.
Running ps aux | grep Claude | grep desktop-features confirms the operon feature flag is returning unavailable:
json{
"operon": {"status": "unavailable"},
"wakeScheduler": {"status": "unavailable"},
"plushRaccoon": {"status": "unavailable"},
"quietPenguin": {"status": "unavailable"},
"coworkKappa": {"status": "unavailable"},
"computerUse": {"status": "supported"},
"chillingSlothLocal": {"status": "supported"},
"ccdPlugins": {"status": "supported"},
"floatingAtoll": {"status": "supported"}
}
Troubleshooting attempted (all unsuccessful):

Logged out/in on both desktop and mobile
Toggled Dispatch off → Cmd+R refresh → back on
Fully quit and relaunched Claude Desktop
Cleared Electron cache (Cache, GPUCache, Code Cache) and relaunched

Environment:

macOS, Apple Silicon
Claude Desktop 1.2773.0
Max plan
Dispatch was working normally prior to the outage

This appears to be a server-side feature flag issue, consistent with #45937 and #45962.

Platform: Windows (not macOS like most reports here)
Date observed: April 15, 2026
Claude Desktop version: Latest (fresh reinstall performed today)
Plan: Pro/Max
Behavior:
Dispatch shows green “Online” status, but will not respond to substantive messages. The “Stop. Are you working on anything?” interrupt command works and returns a response, and messages are marked “Read” — confirming the connection exists. However, any follow-up question or task request goes unanswered.
Steps taken with no resolution:
• Signed out and back in on Claude Desktop
• Fully uninstalled and reinstalled Claude Desktop
• Restarted the app multiple times
Impact:
Unable to use Dispatch for any meaningful work. Had to abandon Dispatch entirely and work directly in Claude Desktop.
Note for Anthropic: This confirms the issue is not limited to macOS — Windows users are affected as well. The partial responsiveness (system pings work, substantive responses don’t) suggests the server-side relay is the failure point, not the local client.

I had the same issue — Dispatch main conversation showing "Desktop appears offline" while individual Cowork tasks worked fine. I put together a debugging script that walks through the common fixes interactively. It ended up resolving it for me (clearing bridge-state.json + restart did the trick).

Sharing in case it helps others:

#!/bin/bash
# fix-dispatch.sh — Debug and fix Claude Dispatch "Desktop appears offline" issue
# Run with: bash ~/fix-dispatch.sh

set -euo pipefail

GREEN='\033[0;32m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
BLUE='\033[0;34m'
BOLD='\033[1m'
NC='\033[0m'

step=0
next_step() {
    step=$((step + 1))
    echo ""
    echo -e "${BLUE}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
    echo -e "${BOLD}Step $step: $1${NC}"
    echo -e "${BLUE}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
}

info()    { echo -e "  ${GREEN}[OK]${NC} $1"; }
warn()    { echo -e "  ${YELLOW}[!!]${NC} $1"; }
err()     { echo -e "  ${RED}[ERR]${NC} $1"; }
detail()  { echo -e "  ${BLUE}-->  ${NC}$1"; }

echo ""
echo -e "${BOLD}Claude Dispatch — Offline Debugger${NC}"
echo -e "Running on $(date)"
echo -e "macOS $(sw_vers -productVersion) ($(uname -m))"

# Step 1: Check if Claude is running
next_step "Check Claude process"
claude_pids=$(pgrep -f "Claude.app" 2>/dev/null || true)
if [ -n "$claude_pids" ]; then
    count=$(echo "$claude_pids" | wc -l | tr -d ' ')
    info "Claude is running ($count processes)"
else
    err "Claude does not appear to be running"
fi

# Step 2: Check network connectivity
next_step "Test network connectivity to Anthropic"
if curl -s --max-time 5 -o /dev/null -w '' https://api.anthropic.com 2>/dev/null; then
    info "api.anthropic.com is reachable"
else
    err "Cannot reach api.anthropic.com"
fi
if nc -z -w 3 api.anthropic.com 443 2>/dev/null; then
    info "Port 443 (TLS/WSS) is open"
else
    err "Port 443 blocked — websockets will not work"
fi

# Step 3: Inspect config files
next_step "Inspect Claude config files"
claude_dir="$HOME/.claude"
bridge_file="$claude_dir/bridge-state.json"
if [ -f "$bridge_file" ]; then
    warn "bridge-state.json exists"
    mod_date=$(stat -f "%Sm" -t "%Y-%m-%d %H:%M" "$bridge_file" 2>/dev/null || stat -c "%y" "$bridge_file" 2>/dev/null | cut -d. -f1)
    detail "Last modified: $mod_date"
    cat "$bridge_file" 2>/dev/null | python3 -m json.tool 2>/dev/null | head -20 || cat "$bridge_file" | head -20
else
    info "No bridge-state.json found"
fi

creds_file="$claude_dir/.credentials.json"
if [ -f "$creds_file" ]; then
    info "Credentials file exists"
else
    err "No credentials file found"
fi

# Step 4: Clear bridge state
next_step "Clear bridge state"
if [ -f "$bridge_file" ]; then
    backup="$bridge_file.backup.$(date +%s)"
    cp "$bridge_file" "$backup"
    info "Backed up to $(basename "$backup")"
    rm "$bridge_file"
    info "Deleted bridge-state.json"
else
    info "No bridge-state.json to clear"
fi

# Step 5: Check Application Support for stale Dispatch data
next_step "Check Application Support for stale Dispatch data"
app_support="$HOME/Library/Application Support/Claude"
if [ -d "$app_support" ]; then
    dispatch_files=$(find "$app_support" -iname "*dispatch*" -o -iname "*bridge*" -o -iname "*offline*" 2>/dev/null || true)
    if [ -n "$dispatch_files" ]; then
        warn "Found Dispatch-related files:"
        echo "$dispatch_files"
        read -p "  Delete these files? (y/N): " confirm
        if [[ "$confirm" =~ ^[Yy]$ ]]; then
            echo "$dispatch_files" | while read -r f; do rm -f "$f"; done
            info "Deleted"
        fi
    else
        info "No stale Dispatch files found"
    fi
fi

# Step 6: Check Claude CLI for token refresh
next_step "Check Claude CLI for token refresh"
if command -v claude &>/dev/null; then
    info "Claude CLI found: $(which claude)"
    read -p "  Run 'claude setup-token' to refresh credentials? (y/N): " confirm
    if [[ "$confirm" =~ ^[Yy]$ ]]; then
        claude setup-token
        info "Token refresh complete"
    fi
else
    warn "Claude CLI not found — install with: npm install -g @anthropic-ai/claude-code"
fi

# Step 7: Restart Claude
next_step "Restart Claude desktop app"
read -p "  Quit and restart Claude now? (y/N): " confirm
if [[ "$confirm" =~ ^[Yy]$ ]]; then
    osascript -e 'tell application "Claude" to quit' 2>/dev/null || pkill -f "Claude.app" 2>/dev/null || true
    sleep 3
    if pgrep -f "Claude.app" >/dev/null 2>&1; then
        pkill -9 -f "Claude.app" 2>/dev/null || true
        sleep 2
    fi
    info "Claude stopped"
    open -a "Claude"
    sleep 5
    if pgrep -f "Claude.app" >/dev/null 2>&1; then
        info "Claude is running again"
    else
        err "Claude did not restart — open it manually"
    fi
fi

echo ""
echo "Done! If still offline, try:"
echo "  1. Toggle Dispatch off/on in settings"
echo "  2. Check for Claude app update"
echo "  3. Log out and back in"

What it does: Checks network, inspects config, clears stale bridge-state.json (with backup), looks for dispatch cache files in Application Support, optionally refreshes CLI tokens, and restarts the app. Each destructive step asks for confirmation first.

My workaround was to move the current bridge-state.json out of the ApplicationSupport/Claude folder and rename it.

Then starting up the Claude app and going through the pairing flow in the Dispatch tab, a new bridge-state.json was created. There was still a conflict and a new bridge-state.json alone didn't fix the issue.

I quit the app, deleted the newly created bridge-state.json file and replaced it with the original file I'd held as backup. Upon restart, Dispatch reconnected.

The dispatch session with the Claude Application is also not working for me it says the Desktop appears Offline, Have tried all workarounds including rm ~/.config/Claude/bridge-state.json and restarting the desktop app to no luck.

Same here. Have you found a solution yet?

Commenting to add a fresh reproduction with logs — this is still broken 15 days after Cowork GA.

macOS 26.4.1, Claude Desktop Claude 1.4758.0 (fb266c). The latter has been updated multiple times since April 9. Symptoms match the original report exactly:

1. Mobile device correctly detects desktop as online,
2. Mobile device sends a message,
3. The message appears on the Mac Desktop UI and is marked "Read",
4. Then just the wiggling activity indicator, forever.

Working:

• Pairing: the mobile app correctly reports online/offline state. Messages don't queue when desktop is offline; they traverse the pairing layer fine when it's online.
• Bridge auth: post-sign-out, there are zero 401s. Message receipt is clean.
• Client state: from reading #41703, deleting bridge-state.json + local-agent-mode-sessions/ does not help, so I haven't tried it.

Fresh capture from tonight (4/24/2026, 21:31–21:35 CDT), main.log, filtered:

21:34:39 [sessions-bridge] Received user message for session cse_...: "Test message..."
21:34:40 [LocalAgentModeSessionManager] Appending skills to system prompt
21:34:40 [LocalAgentModeSessionManager] Using system prompt (103771 chars, 1 segments)
21:34:48 [LocalAgentModeSessionManager] Added scheduled tasks MCP server
21:35:36 [LocalAgentModeSessionManager] SDK version 2.1.119 will be used
21:35:36 [LocalAgentModeSessionManager] Bridge session: disabling renderer-dependent tools
21:35:36 [Spawn:vm] Spawn succeeded in 256ms
21:35:43 [Keepalive] Ping failed: Keep-alive ping timed out

Notes:
Bridge → LocalAgentModeSessionManager handoff works.

• VM spawns cleanly.
• SDK 2.1.119 installs.
• Claude Code process is launched with full arg list including mcp__dispatch__send_message.
• Seven seconds after spawn, keepalive to the process times out and nothing ever returns to the Dispatch thread.

Request: This bug has been duplicated across #40178, #40430, #40958, #41703, #45937, #46093, #49545, #52367 since late March. The "invalid — not Claude Code" label pattern is routing these away from whoever can actually fix them.
→ Can someone please own the Dispatch-thread-handoff failure mode as a single issue?

Desktop version: 1.4758.0 (fb266c)
Account plan: Max tier.

For anyone landing here with the same "Desktop appears offline" symptom: I just filed #53266 with a root-cause investigation that may overlap with this thread. On my account the failure is a hard-coded 10 s timeout in the desktop's [transport:sdk] adapter (POST /worker/register, functions hqr / vVr in the bundled app.asar), which is exceeded whenever the SDK bootstrap takes longer than 10 s — and on power-user setups with many CLI-installed Code plugins + the bundled official skills, it routinely takes 20–90 s.

If you can grep your ~/Library/Logs/Claude/main.log for transport:sdk and you see timeout of 10000ms exceeded retrying every ~10 s, you're hitting the same root cause as #53266. If your logs show a different signature (server-side 503/404, environment ghosting, etc.) it's likely a different root cause and #45937 / #48754 / #49545 capture that better.

We're betting on how long it will take for antropic to recognize the problem and do something about it.

@ZaMpAdAKiNg I have this problem but do not have the "Desktop appears offline" on desktop and "Can't reach your desktop" on mobile symptoms. Further, messages come in from mobile, are visible with Desktop's Dispatch environment, but never get a reply.

fix this pls, so annoying

similar issues for myself previous fixes in this thread have not fixed the bug for myself either, commenting to try new potential fixes

😂 do not do this, it'll nuke every conversation, project and task in cowork (including scheduled tasks)

Update: Resolved — minimal fix identified The issue was caused by a corrupted bridge session in local-agent-mode-sessions/, likely from the April 9th server incidents. Fix that worked: 1. Quit Claude Desktop 2. Delete only the bridge-related data: `` rm -rf ~/Library/Application\ Support/Claude/local-agent-mode-sessions/ rm ~/Library/Application\ Support/Claude/bridge-state.json ` 3. Reopen Claude Desktop This preserves all conversation history, context, and settings — only the bridge relay session is reset. No need to delete claude-code-sessions/ or do a full app data reset. **For others experiencing this:** Back up ~/Library/Application Support/Claude/` first, then delete only those two paths. Your Dispatch context will survive.

Read your Dispatch permanently offline thread. Doing every reinstall and bridge-state reset and still being locked out points to exactly the kind of cloud-side fragility that productized phone-to-Claude-Code workflows have to avoid. I built one that runs entirely off your own Mac, no Anthropic relay, no offline state to debug. Want to see how it works? remote-claude.com

Can confirm this worked on my setup (macOS, Mac Mini, Claude Desktop). Notably, deleting only bridge-state.json was sufficient — I didn't need to remove local-agent-mode-sessions/. Dispatch is back online with all conversation history intact.

Update: in #53266 I posted evidence that Dispatch is now working on my end without any config change (last transport:sdk timeout of 10000ms exceeded failure on 2026-05-02; clean since, with bundled claude-code 2.1.128 + Claude.app 1.6608.0). The 10 s timeout literal is still in app.asar, so the fix appears to be server-side / bootstrap-decoupling rather than a client-side timeout bump.

If your "Desktop appears offline" happens to share the same root cause, you should also see it resolved on the latest desktop build. If it's still broken for you and the log signature is different (server-side 503/404, ghost env, etc.), this is likely a different bug and the discussion in this thread / #48754 still applies.

Windows ARM64 field report: reconnectTransport permanent-silence bug + surgical workaround

Environment: Windows 11 ARM64, Claude Desktop MSIX v1.6608.0.0 (Claude_pzs8sxrjxfjjc)

---

Symptom

Dispatch (Cowork) shows "デスクトップがオフラインのようです" (Desktop offline). Cowork tasks, Code sessions, and Chat all work normally — only the Dispatch↔Desktop bridge is broken. The Desktop icon in Dispatch is grayed out and completely unresponsive.

---

Root-cause trace in main.log

The key signature is a single pair of lines with no subsequent retry attempt:

[sessions-bridge] reconnectTransport called
[sessions-bridge] Transport timed out after 10000ms

After that single 10 s timeout the bridge goes permanently silent. There is no retry loop. The stale environmentId (env_XXXX) and remoteSessionId (cse_XXXX) are then persisted to bridge-state.json. On the next app start those stale IDs are reused, triggering the same failure immediately — explaining why a simple restart does not reliably fix it.

---

bridge-state.json (redacted)

Location: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\bridge-state.json

{
  "<orgUuid>:<spaceId>": {
    "enabled": true,
    "userConsented": true,
    "environmentId": "env_XXXX",
    "remoteSessionId": "cse_XXXX",
    "localSessionId": "local_ditto_<userUuid>",
    "processedMessageUuids": ["... ~50 UUIDs ..."],
    "pendingProcessedAcks": []
  }
}

---

Surgical workaround (no reinstall needed)

1. Fully quit Claude Desktop (system tray → Quit — not just close the window)
2. Edit bridge-state.json
3. Set environmentId and remoteSessionId to null for the affected key (preserve all other fields):

{
  "<orgUuid>:<spaceId>": {
    "enabled": true,
    "userConsented": true,
    "environmentId": null,
    "remoteSessionId": null,
    "localSessionId": "local_ditto_<userUuid>",
    "processedMessageUuids": ["... ~50 UUIDs ..."],
    "pendingProcessedAcks": []
  }
}

1. Restart Claude Desktop → fresh registration succeeds, Dispatch comes back online immediately.

Note: A hard crash + restart also recovered in my case — presumably because the crash prevented bridge-state.json from being flushed with the stale IDs. A clean restart after a normal quit is less reliable because the file gets written before exit.

---

Suggested fix

• Add a retry loop in reconnectTransport with exponential back-off (e.g. 3 attempts before giving up permanently)
• Do not persist environmentId / remoteSessionId to bridge-state.json when the transport has timed out — or clear them on shutdown so a fresh registration is forced on next start

See also: #51684 (same root cause, Windows ARM64 + Cowork sandbox context)

---
Posted via Claude Code with the user's explicit approval. ;)

Hitting this on a much newer build — useful signal that it's not fixed:

• Claude Desktop: 1.7196.1
• macOS: 26.4 (build 25E246)
• Plan: Max

Same symptom: Dispatch shows "Desktop appears offline. Will run when it reconnects." with the desktop app open and signed in on the same account. App is clearly running locally and otherwise functional.

[BUG] Dispatch shows desktop as offline/asleep on Windows 11 Pro despite CoworkVMService running

Related issues: #45937, #46391, #54378

---

Environment

• Windows 11 Pro
• Claude Desktop (latest version)
• Claude Pro plan
• Mobile: Android/iOS (Claude mobile app, latest version)

What's wrong

The mobile app shows the desktop as offline or "asleep" when navigating to Dispatch, even though:

• Claude Desktop is open and running
• CoworkVMService is confirmed RUNNING (Get-Service CoworkVMService returns Running)
• Hyper-V vmms service is confirmed RUNNING
• Keep Awake is toggled ON in Cowork → Dispatch settings
• Cowork itself appears to function normally on the desktop side

The issue is specific to the Dispatch pairing/connection channel.

Steps to reproduce

1. Open Claude Desktop on Windows 11 Pro with Cowork and Dispatch configured
2. Enable Keep Awake in Dispatch settings
3. Open Claude mobile app and navigate to Dispatch
4. Observe: desktop shows as offline or asleep

Troubleshooting already attempted (all failed)

• Sign out and back in on both devices (desktop first, then mobile)
• Force quit and restart Claude Desktop
• Restarted Windows
• Deleted %USERPROFILE%\.claude\bridge-state.json
• Confirmed CoworkVMService is running via PowerShell
• Disabled Windows efficiency mode for Claude process
• Toggled Keep Awake off and back on
• Reinstalled Claude Desktop
• Upgraded to Windows 11 Pro
• Subscribed to Claude Pro plan

Expected behavior
Mobile app connects to desktop via Dispatch and shows it as online.

Actual behavior
Mobile app shows desktop as offline or asleep. No connection established.

Same issue, macOS (Mac Studio M4 Max), Max plan. 5 days now, no support response.

Exact symptom match: mobile Dispatch unreachable ("Can't reach desktop" /
"Endormi"), while Chat works fine and local Cowork New tasks respond normally
on the desktop. Messages from mobile show as "Read" but no response is ever
delivered — same as #40179.

Local diagnostics done: Claude Desktop processes healthy, disk/load fine,
network "Connected", full quit + relaunch of Desktop, latest app version.
Nothing local resolves it — consistent with the server-side pairing/relay
freeze described in #45937 and #49545.

Request: manual server-side reset of the Dispatch pairing state for the account.

Confirming this on Windows (Max plan) — so it is not macOS-specific.

Desktop: Claude Desktop running, machine awake, "Keep active" enabled; Cowork sessions and individual tasks work normally. Mobile Dispatch immediately shows the computer as "Asleep" / "Can't reach your desktop."

In my case it started right after an "Another device is connected" lock loop on the same machine. Troubleshooting that did not help (same as OP):

• Confirmed identical account on both devices; logged out/in on mobile and desktop.
• Killed all Claude processes, restarted, and re-registered in strict order (mobile signed out → desktop log in → let Dispatch settle 1-2 min → then mobile).
• Ruled out local network/proxy (corporate clients closed, no VPN active).
• Mobile shows a single desktop (no duplicate device to select).

Local fixes have zero effect, pointing to a stuck server-side Dispatch relay/registration — consistent with this issue. Adding a Windows + Max data point.

Another Windows data point — BOTH Dispatch and Remote Control fail; bridge-state.json reset didn't help

Same symptom on Windows: the mobile app reports "can't reach your desktop / check that your computer is online and the desktop app is open" while Desktop is open + online and normal Cowork works. Notably, Remote Control (Claude Code CLI) also cannot be reached from the phone — so on this account both phone→desktop paths are down, which points at the relay/handshake rather than any single app's local state.

Environment

• Claude Desktop: 1.11187.4.0 (Microsoft Store / MSIX)
• OS: Windows 11 Home, build 26200
• Plan: paid (Pro/Max)

Tried (none resolved it):

• Updated Desktop + mobile to latest; full quit/relaunch of each; machine restart
• Same account confirmed on both; signed out/in on both; firewall allows Claude; sleep disabled
• Applied this thread's fix: fully quit Desktop, deleted ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\bridge-state.json, reopened, re-paired under Dispatch. File regenerates; phone still cannot reach the desktop.

Adding this because (a) it confirms the issue on the latest Windows MSIX build, and (b) the bridge-state.json reset that worked for earlier reporters does not resolve it here, and Remote Control is affected too — consistent with a server-side relay problem.