›_ Claude Code Issues
Claude Code Issues / #18854

Cowork sessions fail with 'Connection error' - internal MITM proxy blocking api.anthropic.com

Resolved 💬 20 comments Opened Jan 17, 2026 by mikecfisher Closed Jan 27, 2026

What's happening

Cowork sessions completely fail to work. Every time I try to use Cowork, after about 2-3 minutes of waiting, I get:

API Error: Connection error.

This happens 100% of the time. I've tried probably 15+ times over the past few days.

Environment

  • macOS (Darwin 25.2.0)
  • Claude Desktop - latest version (just updated today)
  • Claude Code SDK 2.1.8
  • No VPN running
  • macOS firewall is off
  • UniFi router with no special network security configured

What I tried

  1. Updated Claude Desktop to the latest version - no change
  2. Deleted the VM bundle (rm -rf ~/Library/Application Support/Claude/vm_bundles/) and let it re-download fresh - no change
  3. Restarted my Mac completely - no change
  4. Checked firewall settings - it's off
  5. Made sure no VPN was running - confirmed

Debugging deep dive

I spent a while digging through the logs and I think I found the actual issue.

The VM starts fine

Looking at claude_vm_node.log, the VM boots up successfully:

[VM:start] Step 4/4 complete: connected after 23 polls, 11064ms since boot
[VM:start] Installing SDK: subpath=Library/Application Support/Claude/claude-code-vm, version=2.1.8
[VM:start] SDK installed, total startup time: 85430ms

OAuth token gets approved

In claude_vm_swift.log:

[VM] OAuth token approved successfully
[VM] Process spawned: id=5e568266-79f1-4252-ac8a-d2bfd633055c name=busy-wonderful-mayer command=/usr/local/bin/claude

MCP servers connect

The session audit shows all MCP servers connecting fine:

"mcp_servers":[
  {"name":"Claude in Chrome","status":"connected"},
  {"name":"mcp-registry","status":"connected"},
  ...
  {"name":"cowork","status":"connected"}
]

Then the API call fails

After all that succeeds, the actual API call to Anthropic fails:

{"type":"assistant","message":{"content":[{"type":"text","text":"API Error: Connection error."}]},"error":"unknown"}

Found it: The MITM proxy is blocking api.anthropic.com

I ran a curl test and discovered the issue:

$ curl -v https://api.anthropic.com/v1/messages
* Uses proxy env variable https_proxy == 'http://localhost:64922'
...
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain
< X-Proxy-Error: blocked-by-allowlist

The internal MITM proxy (which I confirmed is Claude Desktop itself via lsof -i :64922) is returning 403 Forbidden with X-Proxy-Error: blocked-by-allowlist when trying to connect to api.anthropic.com.

So the VM's network goes through Claude Desktop's proxy, but that proxy isn't allowing connections to the actual Anthropic API.

The blocklist is empty

I checked the extensions blocklist file and it's empty:

[{"entries":[],"lastUpdated":"2026-01-17T18:36:37.752Z",...}]

And in config.json:

"dxt:allowlistEnabled": false

What I think is happening

It looks like the VM's egress traffic goes through Claude Desktop's MITM proxy for security/isolation, but the allowlist that's supposed to permit api.anthropic.com isn't working correctly. The proxy is blocking the exact domain that Cowork needs to function.

The rest of the networking works fine - I can see in the logs that it successfully fetches from https://claude.ai/api/organizations/.../dxt/blocklist, so outbound HTTPS works in general. It's specifically api.anthropic.com that's getting blocked.

Logs

Happy to provide full logs if helpful. The relevant ones are:

  • ~/Library/Logs/Claude/main.log
  • ~/Library/Logs/Claude/claude_vm_node.log
  • ~/Library/Logs/Claude/claude_vm_swift.log
  • ~/Library/Logs/Claude/sdk_daemon.log

And the session audit files in ~/Library/Application Support/Claude/local-agent-mode-sessions/

View original on GitHub ↗

20 Comments

MarshallOfSound · 5 months ago

@mikecfisher can you drop me your logs? Best way to do so it to send in product feedback via the "bug" button in the bottom left and mention your github username in the form somewhere, I should be able to find it.

mikecfisher · 5 months ago

Thanks so much Samuel I did this a few hours ago actually. However I didn't add my user name but I did include a link to this GitHub issue

mikecfisher · 5 months ago

Hi @MarshallOfSound I resubmitted feedback and tagged my GH username and yours. Let me know if you find anything. Thanks!

Also FYI I tried completely uninstalling Claude Desktop including these files: 

  ✓ /Applications/Claude.app
  ✓ ~/Library/Application Support/Claude
  ✓ ~/Library/Caches/com.anthropic.claudefordesktop
  ✓ ~/Library/Logs/Claude
  ✓ ~/Library/HTTPStorages/com.anthropic.claudefordesktop
  ✓ ~/.local/share/Claude

and the issue persists.

drjagan · 5 months ago

I have the same issue. I tried deleting the ~/Library/Application Support/Claude/vm_bundles/ folder and restarted Claude.
Claude did the 'Setting up Claude's workspace..." again but got confused with the sessions. I might have to try deleting the calude-code-vm, claude-code folders to see if claude will recreate it all afresh and test

But I hope there will be a better elegant fix and solution.

Edit: Found the culprit - Cloudflare's Warp.

CLoudflare's warp was inhibiting Claude Cowork. Switching Warp off resolved the issue.

mikecfisher · 5 months ago

Sadly still broke for me in Claude 1.1.673 (5a47b0)

charlesriccardi · 5 months ago

I am experiencing the same thing, unfortunately. Is there anything I can do? I paid for pro so that I can do this with more limits.

charlesriccardi · 5 months ago

It looks like it got fixed for me in the latest release, which was like 2 min. ago.

mikecfisher · 5 months ago

Sadly still broke for me in Claude 1.1.799 (2e02b6)

chrjohns · 5 months ago

Not working for me either in Claude 1.1.799 (2e02b6)

Sarks0 · 5 months ago

Solution: Mullvad VPN daemon was the culprit

I experienced the same "API Error: Connection error" issue. After extensive diagnostics, I found that Mullvad VPN was causing the problem - even though it showed as "Disconnected."

Root Cause

The Mullvad daemon (mullvad-daemon) runs as a root process and persists even after:

  • Disconnecting from VPN
  • Quitting the Mullvad app

This background daemon interferes with Claude Desktop's internal MITM proxy and the Cowork VM's network traffic.

Configurations tested (all failed with daemon running):

mullvad split-tunnel set on
mullvad split-tunnel app add "/Applications/Claude.app/Contents/MacOS/Claude"
mullvad split-tunnel app add "/Applications/Claude.app"
mullvad split-tunnel app add "/Applications/Claude.app/Contents/Frameworks/Claude Helper.app/Contents/MacOS/Claude Helper"
mullvad split-tunnel app add "/Applications/Claude.app/Contents/Frameworks/Claude Helper (GPU).app/Contents/MacOS/Claude Helper (GPU)"
mullvad split-tunnel app add "/Applications/Claude.app/Contents/Frameworks/Claude Helper (Renderer).app/Contents/MacOS/Claude Helper (Renderer)"
mullvad lan set allow
mullvad dns set default
mullvad lockdown-mode set off

None of these configurations resolved the issue while the daemon was running.

Solution

The only working solution is to fully stop the Mullvad daemon (not just disconnect/quit the app):

sudo launchctl bootout system /Library/LaunchDaemons/net.mullvad.daemon.plist

Then restart Claude Desktop - Cowork works immediately.

To restart Mullvad later:

sudo launchctl bootstrap system /Library/LaunchDaemons/net.mullvad.daemon.plist

Environment

  • macOS Darwin 25.2.0 (Apple M4)
  • Claude Desktop 1.1.799
  • Mullvad VPN installed (but "disconnected")

Notes

This is similar to the Cloudflare Warp issue mentioned by @drjagan. VPN tools with always-on background daemons can conflict with Claude's internal networking even when not actively connected.

Adding my experiance here with Mullvad encase someone else also comes into the same problem.

mikecfisher · 5 months ago

I've been experiencing this issue and spent a while debugging it. Wanted to share my findings in case it helps others or the team.

My Setup

  • macOS with Docker Desktop, Bitdefender endpoint security, and previously had ProtonVPN and Palo Alto GlobalProtect installed
  • The co-work VM uses vmnet networking with a bridge100 interface (192.168.64.0/24 subnet)

What I Found

Sessions are now passing after update: After updating to Claude 1.0.19 (2e02b6), sessions complete successfully in the backend. Looking at ~/Library/Logs/Claude/main.log, I consistently see:

cycle_health: 'healthy'

Sessions finish with exit code 0 and run for several minutes. But the UI still shows "API Error: Connection error".

NAT is broken but sessions still work: Running curl --interface bridge100 times out - NAT masquerading for the VM subnet isn't working on my machine. However, sessions still complete because the actual API traffic goes through a MITM proxy over virtio, not through the bridge interface.

Things I Tried (None Fixed the UI Error)

  1. Stopped Docker's vmnetd - Thought it might conflict with the VM's vmnet networking. No change.
  2. Completely uninstalled ProtonVPN - Found its WireGuard network extension was still active. Uninstalled the app entirely. Extension now shows [activated disabled]. No change.
  3. Removed Palo Alto GlobalProtect daemon - No change.
  4. Tried to disable Bitdefender - Can't via CLI, it protects itself (Boot-out failed: 5: Input/output error). Still running.

Potential Lead: React Query UUID Errors

Looking at ~/Library/Logs/Claude/claude.ai-web.log, I found these errors:

[REACT_QUERY_CLIENT] QueryClient error: Error: path.conversation_uuid: Input should be a valid UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-fA-F-], found `l` at 1

The session IDs in the logs look like local_07008919-cce3-420c-a00b-8453b23b8496 - they're prefixed with local_ which isn't a valid UUID format. The frontend React Query client seems to be trying to use these as API conversation UUIDs and failing validation.

Hypothesis: The backend completes successfully, but when the frontend tries to sync or display results using these local_* prefixed IDs as UUIDs, it fails validation and shows the generic "API Error: Connection error" message. This would explain why:

  • Backend logs show healthy completions
  • The exact error message "API Error: Connection error" never appears in any log file
  • The error only shows in the UI

Uncertainties

  • I can't fully rule out Bitdefender since I couldn't disable it
  • Not 100% sure the UUID issue is the root cause, just a strong hypothesis based on the logs
  • The broken NAT is suspicious but doesn't seem to be blocking sessions

Would be interested to know if others seeing this issue also have these React Query UUID errors in their web logs.

Barton0411 · 5 months ago

same issue，waiting for fixed

ayazhafiz · 5 months ago

Having the same issue. I had dnsmasq running and it wasn't answering queries on a bridge network interface (in my case I assume Claude Cowork was using an interface called bridge100). Adding listen-address=192.168.64.1 (being the IP of the interface) to dnsmasq.conf resolved it.

mikecfisher · 5 months ago

@ayazhafiz this was it! Added listen-address=192.168.64.1 to my dnsmasq.conf, restarted it with sudo brew services restart dnsmasq, and cowork finally works. Thanks for posting this.

curiousgeorgios · 5 months ago
Having the same issue. I had dnsmasq running and it wasn't answering queries on a bridge network interface (in my case I assume Claude Cowork was using an interface called bridge100). Adding listen-address=192.168.64.1 (being the IP of the interface) to dnsmasq.conf resolved it.

fuck i love open-source - that was the issue for me and this fixed it^ 🫶

nish-b · 5 months ago

Still experiencing this, and I have company-mandatory Cloudflare WARP on which I imagine is causing the issue. But can't disable to confirm :(

MarshallOfSound · 5 months ago

Merging into #18006 as the same issue

kimsyversen · 5 months ago

Got the same issues. Using Claude 1.1.886 (ef5d26) 2026-01-24T18:00:47.000Z.

Tailing ~/Library/Logs/Claude/claude.ai-web.log gives

2026-01-27 18:32:16 [error] Refused to connect to 'https://a-api.anthropic.com/v1/m' because it 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".

2026-01-27 18:32:16 [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-01-27 18:32:16 [error] Error sending segment performance metrics TypeError: Failed to fetch
2026-01-27 18:32:26 [error] [REACT_QUERY_CLIENT] QueryClient error: Error: path.conversation_uuid: Input should be a valid UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-fA-F-], found `l` at 1
tweedmann · 5 months ago

Still experiencing this (Claude 1.1.886 (ef5d26) 2026-01-24T18:00:47.000Z)

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.