[BUG] Cowork Dispatch not responding on macOS
Open 💬 30 comments Opened Mar 28, 2026 by lerdpisith
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Bug: Cowork Dispatch not responding on macOS
- VM boots successfully but IPv4 route unavailable
- Missing entitlement: com.apple.vm.networking
- Only has: com.apple.security.virtualization
- Log: rate_limit_event loop → QueryClient Not found → UI crash
- macOS Virtualization VM subnet 172.16.10.x has no bridge interface
What Should Happen?
Expected Flow:
1. Claude Desktop starts VM (Ubuntu 22.04)
↓
2. VM gets IP: 172.16.10.3/24 via bridge interface
↓
3. coworkd confirms IPv4 route AVAILABLE (not NOT_CONNECTED)
↓
4. MITM proxy on /var/run/mitm-proxy.sock connects to Anthropic API
↓
5. Dispatch session handshakes successfully
↓
6. Message sent → processed → response returned to UI
↓
7. No rate_limit_event loop, no QueryClient errors---
What's missing for this to work:
The app needs com.apple.vm.networking entitlement so macOS allows the VM to:
- Create a proper bridge at
172.16.10.x - Route traffic between VM ↔ host ↔ Anthropic API
- Let
coworkdconfirm the route is ready before Dispatch tries to connect
---
In short — the VM boots, but macOS blocks its network, so Dispatch never gets a live session. Anthropic needs to re-sign the app with the missing entitlement. This is fully on their end to fix, not something you can work around on your machine.
Worth including all of this in your GitHub issue — it's a clean, reproducible root cause that their team can act on directly.
Error Messages/Logs
Here's a clean summary of all error messages and logs for your GitHub issue report:
---
**1. Rate Limit Loop** *(root trigger)*
[LOCAL_SESSION] unknown sdk message type: rate_limit_event
Fired continuously every ~1 second for minutes at a time. The app doesn't know how to handle this new SDK message type, causing a retry loop.
---
**2. UI Crash** *(result of loop)*
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
[REACT_QUERY_CLIENT] QueryClient error: Error: Not found
Fires repeatedly after rate limit loop starts. Frontend loses reference to the Dispatch session and crashes silently — message shows as "read" but no response is returned.
---
**3. Memory Leak** *(from not restarting)*
MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
11 listeners added: AutoUpdater / AppPreferences
App accumulates event listeners over time without cleanup, making the crash loop worse.
---
**4. VM Network Not Ready** *(kernel log)*
[KERNEL] [coworkd] IPv4 route not yet available, emitting NOT_CONNECTED
[KERNEL] [coworkd] configuring static IP on enp0s1: 172.16.10.3/24 gateway=172.16.10.1
VM boots successfully but cannot establish network route. No matching bridge interface exists on the host side for `172.16.10.x`.
---
**5. Missing Entitlement** *(root cause)*
codesign -dv --entitlements - /Applications/Claude.app
[Key] com.apple.security.virtualization ← only this exists
`com.apple.vm.networking` is absent. macOS blocks VM network access without it, so the bridge never forms and `coworkd` stays in `NOT_CONNECTED` state permanently.
---
**Full Chain:**
Missing entitlement (com.apple.vm.networking)
→ VM has no bridge at 172.16.10.x
→ coworkd: NOT_CONNECTED
→ Dispatch retries repeatedly
→ rate_limit_event loop (unknown to SDK handler)
→ TypeError: Cannot read properties of undefined
→ QueryClient: Not found
→ UI shows "read" but never responds
→ EventEmitter memory leak after prolonged session
---Steps to Reproduce
Environment
OS: macOS (Apple Silicon)
App: Claude Desktop (latest version)
Plan: Pro / Max
Feature: Cowork Dispatch (research preview)---
Prerequisites
- Claude Desktop app installed and running
- Cowork Dispatch set up and enabled
- Claude mobile app installed and paired with desktop
---
Steps
1. Open Claude Desktop app on macOS
2. Navigate to Cowork → Dispatch in the left sidebar
3. Type any message in the Dispatch input and send
4. Observe message shows as "read" but no response is returned
5. Open Terminal and run:
tail -f ~/Library/Logs/Claude/claude.ai-web.log
6. Send another message in Dispatch
7. Observe continuous rate_limit_event warnings firing every ~1 second
8. Wait ~1-2 minutes — observe TypeError and QueryClient errors appear
9. Run entitlement check:
codesign -dv --entitlements - /Applications/Claude.app 2>&1 | grep -i "virtual|hypervisor|network"
10. Observe only com.apple.security.virtualization is present
— com.apple.vm.networking is missing---
Expected Result
- Dispatch processes the message
- VM establishes network route at 172.16.10.x
- coworkd confirms IPv4 route AVAILABLE
- Response is returned in the UIActual Result
- Message marked as "read" with no response
- coworkd logs: IPv4 route not yet available, emitting NOT_CONNECTED
- rate_limit_event fires in loop (unhandled SDK message type)
- TypeError: Cannot read properties of undefined (reading 'includes')
- QueryClient error: Not found
- UI silently fails — no error shown to user---
Verification Command
# Check VM network bridge (should show 172.16.10.x — it won't)
ifconfig | grep -A3 "bridge|vmnet|vz"
# Check entitlements (missing com.apple.vm.networking)
codesign -dv --entitlements - /Applications/Claude.app 2>&1 | grep -i "virtual|hypervisor|network"
# Check kernel log
cat ~/Library/Logs/Claude/claude.ai-web.log | grep -E "rate_limit|NOT_CONNECTED|Not found|TypeError"---
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.86 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
30 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Same issue. Mac Mini M2, headless, Claude Desktop 1.1.9310, macOS 26.0.1 beta.
Messages show as ✓ Read, no response ever appears.
I am having the same issue. Paired. Sent message (either from phone or in dispatch page of macOS desktop), it receives it but never get a response. I have reset App data and re-paired. Same result. I send message from phone, shows up on Desktop dispatch page, thinks about it, and then no response.
mike@mac ~ % tail -f ~/Library/Logs/Claude/claude.ai-web.log
2026-03-28 23:17:35 [warn] [LOCAL_SESSION] unknown sdk message type: rate_limit_event
2026-03-28 23:18:22 [error] Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
2026-03-28 23:18:23 [error] [REACT_QUERY_CLIENT] QueryClient error: Error: Not found
2026-03-28 23:23:50 [error] Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
2026-03-28 23:23:50 [error] [REACT_QUERY_CLIENT] QueryClient error: Error: Not found
2026-03-28 23:26:00 [error] Connecting to 'https://a-api.anthropic.com/v1/m' violates the following Content Security Policy directive: "connect-src 'self' https://api.segment.io https://.segment.io https://.segment.com https://a-cdn.anthropic.com https://.google.com https://.facebook.com https://.facebook.net https://.doubleclick.net". The action has been blocked.
2026-03-28 23:26:00 [error] Fetch API cannot load https://a-api.anthropic.com/v1/m. Refused to connect because it violates the document's Content Security Policy.
2026-03-28 23:26:00 [error] Error sending segment performance metrics TypeError: Failed to fetch
2026-03-28 23:26:01 [error] Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
2026-03-28 23:26:01 [error] [REACT_QUERY_CLIENT] QueryClient error: Error: Not found
2026-03-28 23:26:34 [error] Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
Same issue here.
Environment:
Symptoms:
Steps taken (no fix):
Matches the root cause described here — missing com.apple.vm.networking entitlement.
Same issue, confirmed on Mac Mini M4, Claude Desktop 1.1.9310, Pro plan. Same missing entitlement.
Update on this - I complete removed Claude Desktop from my mac and the iOS Claude app from my phone. I was pretty thorough about it including removing all related files and keychains. I then re-installed everything clean and Dispatch is now working for me.
Same issue here. Claude 1.1.9493 (b58a0b) on macOS. Everything except Dispatch works.
Same problem here
Same problem, too
Same issue here.
Mac M3
Claude 1.1.9493 (b58a0b)
Max plan
Dispatch receives messages (marked as read), shows "thinking" briefly, then nothing comes back. Cowork sessions work fine.
Still seeing this on 1.1.9493 (b58a0b) on macOS Apple Silicon. Dispatch shows "desktop is offline" persistently — full app restart does not resolve it. The 1.1.9493 patch did not fix this for me.
Coming back to say that I've fixed my issue. I didn't have to delete or reinstall the iOS app. I'm on the latest version there. But I _did_ have to not only delete the macOS app, but first I logged out of it completely, then deleted it, then looked through my ~/Library folder for anything Claude related and deleted quite a few things that looked like caches related to Claude. Obviously, there's risk here because you might delete some context or something you'd prefer to keep.
I didn't delete literally everything Claude-related that I found, but I deleted as much as I dared to without deleting anything that looked like something I wanted to keep. I wish I kept a log, but I didn't. Sorry.
But after I did all that, I re-downloaded Claude, now at version 1.1.9669 (aea25d), and Dispatch suddenly flooded in with all the old messages I had typed, and Claude was like "Wait, what? Sorry about the silence, yes I'm here." etc. And I can see the dispatch messages on my phone again.
Same thing worked for me too.
Y'all are my hero. Thanks for this fix. Cowork is back up and working.
Same issue here. macOS, Claude Desktop latest version.
Log from
~/Library/Logs/Claude/claude.ai-web.log:The
network errorat 13:40 appears to be the trigger, followed by the UI crash (TypeError: Cannot read properties of undefined) at 13:43. Dispatch shows messages as read but never responds. Norate_limit_eventloop visible in my logs, but theQueryClient: Not foundandTypeErrorpattern matches exactly.+1 on the missing
com.apple.vm.networkingentitlement hypothesis.This issue still exists on my MacBook Pro (current os) and iPhone/ipad Claude 1.260330.1 iOS. Frustrating. Messages sync across all three form factors, but there is no response April 4, 7:32 PST
I resolved my issue…
I had Claude Code running under a different macOS user session (another logged-in user instance in the background).
macOS allows multiple user sessions to remain active simultaneously, and this created a conflict with Claude’s Dispatch connection.
Fix:
• Fully log out of all other macOS user sessions
• (Fast User Switching → log out completely, not just switch)
• Restart claude remote-control
• Relaunch Claude Desktop
After doing this, Dispatch immediately connected and worked as expected.
Still experiencing this on v1.569.0 (macOS, Apple Silicon)
Confirming the missing entitlement is still present on the latest build:
com.apple.vm.networkingis still missing. Dispatch shows "Desktop appears offline. Will run when it reconnects." — standard Cowork sessions work fine.This is a regression from earlier versions where Dispatch worked correctly. Would appreciate Anthropic re-signing the app with the missing entitlement.
Same issue here on Version 1.569.0 (49894a), Apple M4 Pro and macOS Tahoe Version 26.3.1 (a)
Adding some historical log data from coworkd.log that might help narrow this down further, in case it's useful to others or to engineering.
What the timeline shows:
Looking back through coworkd.log, the IPv4 route issue isn't new — it appears to be a race condition that has existed since at least January. The difference is how often the race is won vs lost:
The sequence when it fails (every time):
The sequence when it succeeds (rare):
The pattern suggests coworkd checks route availability before configuring the static IP, and doesn't retry after configuration. So if the route isn't ready at that exact moment, it stays NOT_CONNECTED until the next restart. This might explain why some users see it work intermittently — it's timing-dependent on each launch.
Also worth noting for anyone debugging: the subnet change from 192.168.64.x to 172.16.10.x appears in logs around March 9, which correlates with when some users report the issue worsening. Not sure if that's meaningful but flagging it.
Cross-referencing a related comment with similar findings in #40958 in case it helps piece things together.
Same issue here. macOS, Mac mini, Claude Desktop latest (Timestamp April 9, 2026).
Dispatch receives messages (marked as "read") but never responds.
Confirmed:
com.apple.vm.networkingentitlement is missing.Shows only
com.apple.security.virtualization— nocom.apple.vm.networking.Full entitlements list:
Regular Cowork works fine, only Dispatch is affected.
Can anyone propose a way to force com.apple.vm.networking as a workaround?
Reporting the same issue on the latest Claude Desktop. Hope this data point helps.
Environment:
Entitlement check:
com.apple.vm.networkingis still absent.What I tried:
bridge-state.jsonandlocal-agent-mode-sessions→ Dispatch UI reset successfully to fresh setupSummary: Same root cause as described in this issue. VM boots but cannot establish network route. This has persisted across multiple Desktop versions (tested since early April 2026).
Happy to provide any additional logs or diagnostics if helpful.
Confirming this on a fresh setup with the latest everything — the missing
entitlement is still not fixed in Claude Desktop 1.2581.0.
Environment:
mobile Claude 1.2600409.1 (19 hours old)
Verification per this issue:
$ codesign -dv --entitlements - /Applications/Claude.app 2>&1 \
| grep -iE "virtual|hypervisor|network|vm\."
[Key] com.apple.security.virtualization
Only com.apple.security.virtualization is present. com.apple.vm.networking
is missing, matching the root cause described in this issue.
Symptom: Dispatch messages sent from the Mac, iPad, and iPhone all show
"Read" and never receive a response. Identical behavior from all three
clients, which rules out a client-side issue.
This was auto-flagged "invalid." It is not invalid. Requesting triage.
Follow-up to my earlier comment — withdrawing support for the
entitlement theory.
After more testing, I confirmed that Dispatch responses are actually
being generated and delivered to my Mac successfully. They just don't
render in the main chat pane. They're visible via "See background
tasks" (the pulldown menu next to the "Dispatch" title).
Test results (M5 Pro, macOS 26.4.1, Claude Desktop 1.2581.0):
"From the mac: What is 7 times 3?" → "7 times 3 is 21." ✅
"From the iPad: What is 7 times 4?" → "7 times 4 is 28." ✅
Both correct, both visible in background tasks.
My codesign output still shows only com.apple.security.virtualization
with no com.apple.vm.networking — yet the VM is clearly routing traffic
to Anthropic and back. So the missing entitlement reported in this
issue does not appear to be the actual cause of the "Read but no
response" symptom. If it's a real problem at all, it's independent.
The actual bug is in the main chat rendering layer and is better
tracked at #40179. Posting this here so others aren't misdirected
chasing the entitlement angle.
Reproducing on macOS Tahoe 26.5 — entitlement confirmed missing
Adding a data point to help prioritise the re-sign.
Setup
Symptom
Dispatch pairing fails consistently. Phone never establishes the link to the desktop session.
Entitlement check
Only
com.apple.security.virtualizationis present.com.apple.vm.networkingis absent, which matches the root cause described in this issue. On Tahoe 26 the tightened entitlement enforcement turns this into a hard block — no user-side workaround appears to exist.Related: #41525 is collecting downstream pairing-failure reports that all trace back here.
Happy to provide a full
codesign -dv --entitlements -dump orlog streamoutput around a pairing attempt if useful.I was able to get past this finally by using the Desktop -> Dispatch tab. Click the Dispatch dropdown button up top. Choose Clear memory and Delete conversation. (Actually can't remember which one it was that definitely fixed it, but might start with Delete conversation. I may have also tried Clear background tasks...)
It's been a few weeks since I did it and Dispatch started working again for me, which is why I'm not sure.
Anyways, point is that probably one of these will fix it for y'all. It turned out for me at least that maybe the issue specified here is a red herring.
YMMV! Unsubscribing now from this issues. ;)
not working for me... [Key] com.apple.security.virtualization ... waiting for a solution
Adding to this issue as another affected Tahoe user, on the customer-facing side.
Profile. Primary Owner of a Team plan organization at Anthropic (legal practice, single firm). Effective monthly spend with Anthropic across Team seats, Claude Code, and API usage in the high four-figures USD range. Cowork bash sandbox is the backbone of our document-processing workflow over an active multi-thousand-document case file.
Environment.
Verification (pre and post clean reinstall, identical result).
$ codesign -dv --entitlements - /Applications/Claude.app 2>&1 | grep -i "virtual|network|hypervisor"
[Key] com.apple.security.virtualization
com.apple.vm.networkingis missing. Onlycom.apple.security.virtualizationis present.Symptom. Every bash sandbox command returns immediately on the client side:
Cannot read properties of undefined (reading 'split')
Chrome MCP and other Cowork tools work normally — only the bash sandbox is broken, consistent with the missing VM networking entitlement and with the root cause documented in this issue.
Clean reinstall performed, no effect on the missing entitlement. Removed
/Applications/Claude.app, cleared~/Library/Caches/com.anthropic.claude{,fordesktop},pkill -9 -f Claude, downloaded fresh dmg from claude.com/download, drag-drop install, signed in, re-ran codesign. Entitlement still missing. As multiple users have noted in this thread and the linked issues (#41525, #46661, #58495), this is in the signed binary distributed by Anthropic and cannot be worked around client-side.Business impact. Two months and counting since the root cause was first reported here (28/03/2026). At a paying customer level, the bash sandbox blocker has forced our firm into manual fallbacks for every workflow that requires file extraction, OCR, or scripted processing of the case-file corpus. Filed Anthropic support ticket #215474479339707 with full technical detail; the response loop confirmed the issue is tracked but with no ETA or escalation path available at the Team plan tier.
Ask. ETA on a re-signed Claude Desktop release for macOS Tahoe with
com.apple.vm.networkingincluded. If an internal preview or TestFlight build is available for affected customers willing to validate, please consider opening it up.Happy to provide additional logs or run any diagnostic commands the engineering team needs.
I completely forgot to reply to this, but thank you! This workaround also worked for me! Just need Anthropic to actually fix the underlying cause, but definitely works as a bandaid.