›_ Claude Code Issues
Claude Code Issues / #17868

Claude Desktop Cowork tab fails to connect - ERR_CONNECTION_RESET at auth step

Status Closed — not planned
Reported on v2.1.5
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 12 comments · opened Jan 13, 2026 · closed Apr 1, 2026

Issue

Claude Desktop Cowork tab fails to connect with "API Error: Connection error" while regular chat tab works perfectly.

Environment

  • macOS Darwin 25.1.0
  • Claude Desktop (latest version)
  • Claude Code VM SDK version: 2.1.5

Symptoms

  • Regular chat tab works perfectly
  • Cowork tab fails with "API Error: Connection error"
  • Issue persists after app restart and full computer restart

Error from logs (main.log)

2026-01-13 12:38:07 [error] Session initialization failed for local_c05e8141-a6d2-4106-b6b4-4ece86116fc9: net::ERR_CONNECTION_RESET
2026-01-13 12:38:07 [info] [EventLogging] Sending event: lam_session_initialization_failed | metadata: {
  failed_step: 'auth',
  error_message: 'net::ERR_CONNECTION_RESET',

2026-01-13 12:48:46 [error] Session initialization failed for local_7723f28c-4151-4bdd-a10c-6f551bebf022: net::ERR_CONNECTION_RESET
2026-01-13 12:48:46 [info] [EventLogging] Sending event: lam_session_initialization_failed | metadata: {
  failed_step: 'auth',
  error_message: 'net::ERR_CONNECTION_RESET',

VM logs show successful startup (claude_vm_node.log)

2026-01-13 13:14:56 [info] [VM:start] SDK installed, total startup time: 5500ms
2026-01-13 13:15:09 [info] [Spawn:vm] id=723598a6-71ef-428a-ab48-3c76f24d4a9a Spawn succeeded

Analysis

  • VM initializes correctly
  • MCP servers connect successfully
  • Failure occurs specifically at the auth step during session initialization
  • Connection is being reset (ERR_CONNECTION_RESET) when attempting to authenticate cowork sessions
  • Regular chat authentication works, suggesting the issue is specific to the cowork/local agent mode auth endpoint

Network verification

  • ping api.anthropic.com succeeds
  • curl https://api.anthropic.com returns 405 (expected without auth)
  • No VPN or network filtering software active

Suspected cause

Server-side issue with cowork session authentication endpoint.

View original on GitHub ↗

12 Comments

saralobkovich · 7 months ago

Experiencing the same issue. Adding additional diagnostic info:

  • Environment: Mac desktop app v1.1.381, macOS, Max plan
  • Symptoms: Identical — Cowork hangs at "sending request" with ERR_CONNECTION_RESET. Chat works. Code works. Only Cowork fails.
  • Additional finding from Console.app: Every Cowork attempt produces this error:
  • tccd: Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for responsible={TCCDProcess: identifier=com.anthropic.claudefordesktop}
  • Also: TCCDProcess identifier=com.anthropic.claudefordesktop.helper is not a TCC manager for service: kTCCServiceScreenCapture
  • This suggests the Mac desktop app binary is missing the com.apple.security.automation.apple-events entitlement in its code signature, which may be causing the auth step to fail.
  • Troubleshooting completed: Fresh reinstall, cleared all caches, granted all available permissions, reset TCC permissions via tccutil, verified network connectivity. None resolved the issue.
  • The entitlement issue appears every time Cowork attempts to start, and may be the root cause of the ERR_CONNECTION_RESET at the auth step.

I've had the Cowork tab since installing the updated version of the app (including today's update) and have not had a Cowork request complete, yet.

jakekunk · 7 months ago

Seeing the same problem. Was excited to put Cowork through its paces, but @saralobkovich has summarized my experience identically.

TCC log analysis (1 hour window):

  • 44 blocked kTCCServiceAppleEvents requests
  • 100% failure rate for Cowork
  • Chat and Code tabs work normally

Errors observed:
tccd: Prompting policy for hardened runtime; service: kTCCServiceAppleEvents
requires entitlement com.apple.security.automation.apple-events but it is
missing for accessing={TCCDProcess: identifier=com.anthropic.claudefordesktop}

Additional TCC errors in the same logs:

  • kTCCServiceAccessibility requests without

com.apple.private.tcc.manager.check-by-audit-token entitlement (10+ occurrences)

  • kTCCServiceScreenCapture failures with Claude Helper
  • "failed to find Application URL for bundle ID: com.anthropic.claudefordesktop"

Fix required: Add com.apple.security.automation.apple-events to the app's
entitlements.plist and re-sign the build.

To reproduce the TCC log capture:
```bash
log show --predicate 'process == "tccd"' --last 1h > ~/tccd_log.txt
grep -i "claude\|anthropic" ~/tccd_log.txt

TopherTimeMachine · 7 months ago

same problem here. seems to be issues depending on different ISPs that I connect to. Using CenturyLink right now and it's failing.

saralobkovich · 7 months ago

ETA 2: Update: I was experiencing similar ECONNRESET errors with Claude Code on the same Mac. Changing MTU to 1492 (sudo networksetup -setMTU Ethernet 1492) resolved the Claude Code connection issues on CenturyLink, but Cowork still fails with the same ERR_CONNECTION_RESET error.
This suggests Cowork may have a separate OAuth-related issue beyond the network MTU problem.

ETA: Claude code worked for a few minutes then failed again with the ECONNRESET errors. Back to the troubleshooting drawing board.

Original post:

Interesting -- I'm also on CenturyLink (although it has failed on other ISPs, too). I DID just troubleshoot an issue affeting Claude Code on my mac that was happening alongside this -- I don't know if these are related or unrelated.

Claude Code was failing to authenticate with repeated ECONNRESET connection errors because no OAuth token was stored in the configuration, even though account details were present.

The OAuth flow completes successfully and generates a valid token, but the browser callback page at https://platform.claude.com/oauth/code/callback returns ERR_CONNECTION_RESET. Despite the browser error, the token is actually generated and displayed in the terminal.

Workaround for Claude Code:

  1. Run claude setup-token
  2. Click "Authorize" in browser (ignore the ERR_CONNECTION_RESET error)
  3. Copy the token from terminal output
  4. Set environment variable: export CLAUDE_CODE_OAUTH_TOKEN=<token>
  5. Add to ~/.zshrc for persistence

Claude Code now works perfectly with this workaround.

Could Cowork have the same OAuth token issue, but without an equivalent environment variable workaround? The app may need the OAuth flow to complete successfully in a browser to store credentials?

Environment:

Mac Mini, macOS Tahoe 26.2
Claude Code v2.1.19 - WORKING with workaround
Cowork - Still failing, awaiting fix

saralobkovich · 7 months ago

The issue is resolved for me after the update earlier this week!

chriskarlinlaw-hash · 6 months ago

Remains an unresolved issue for me

jakekunk · 6 months ago

@saralobkovich

Common thread here--I too use CenturyLink. Setting up via a mobile hotspot instead of my home network seems to resolve the issue, but if I use my CenturyLink connection still does not work, even after updates. I will give the workaround you mentioned a shot, though!

joan-anthropic · 6 months ago

hi! for folks hitting this on cowork, would you mind dropping your logs via the feedback dialog and mention github issue #17868 in your response? that'll help us investigate further. thanks!

sienioApius · 6 months ago

Root cause identified: MTU/MSS mismatch with VPN tunnels

After extensive debugging (firewall logs, VM logs, network analysis), I've identified the root cause for users running a VPN (confirmed with GlobalProtect, likely affects any VPN):

The problem

The Cowork VM (Virtualization.framework) sets MTU 1400 on its internal enp0s1 interface (hardcoded in coworkd). Traffic flows through:

VM enp0s1 (MTU 1400) → bridge100 (MTU 1500) → utun VPN tunnel (MTU ~1300) → Internet

The MITM proxy inside the VM opens TCP connections to api.anthropic.com and negotiates MSS based on its 1400 MTU. The resulting TCP segments are too large for the VPN tunnel (MTU ~1300), causing:

  • Fragmentation / dropped packets
  • tcp-rst-from-server after ~15 seconds
  • Eventually ECONNRESET after ~185 seconds timeout

Evidence

  • Firewall traffic logs show tcp-rst-from-server sessions — all ~15s elapsed, ~4KB received
  • No SSL decryption, no threat triggers, no blocked rules — firewall is NOT the cause
  • Simple reachability checks pass (small packets), but streaming API calls fail (large packets)
  • curl from the host works fine (negotiates MSS on the VPN interface directly)

Confirmed workaround: PF MSS clamping

Clamping TCP MSS on the bridge interface via macOS packet filter fixes the issue permanently:

# Apply immediately
echo 'scrub on bridge100 reassemble tcp max-mss 1220' | sudo pfctl -m -f -
sudo pfctl -e

MSS 1220 + 40 bytes (IP+TCP headers) = 1260, which fits safely within a typical VPN tunnel MTU of ~1300.

Persistent fix (survives reboot)

Create /etc/pf.anchors/com.cowork-mss:

scrub on bridge100 reassemble tcp max-mss 1220

Edit /etc/pf.conf (PF enforces strict ordering: scrub → nat → rdr → filter):

scrub-anchor "com.apple/*"
scrub-anchor "com.cowork-mss"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"

load anchor "com.cowork-mss" from "/etc/pf.anchors/com.cowork-mss"

Create a LaunchDaemon to load the anchor at boot, or deploy via MDM.

What did NOT help

  • Changing MTU on bridge100 / vmenet0 via ifconfig — VM's coworkd overrides to 1400 internally
  • Restarting the VM alone — only a full Claude Desktop restart + MSS clamping worked

Suggested fix for Anthropic

The Cowork VM should either:

  1. Detect the host's effective MTU (considering VPN tunnels) and set enp0s1 MTU accordingly
  2. Apply MSS clamping inside the VM on outbound connections
  3. Lower the default MTU from 1400 to something safer like 1280 (IPv6 minimum MTU)

---

Environment: macOS 15.5, Claude Desktop 1.1.4498, VPN tunnel MTU ~1300

piotrekkaminski · 6 months ago

https://github.com/anthropics/claude-code/issues/17868#issuecomment-3972541938 is what helped me so far - but I had to clamp on en0 (don't use a VPN) and restart claude after the change.

github-actions[bot] · 5 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 4 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.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

This issue appears in the ranked issue list on these topic pages, alongside a backlog trend for the whole topic.

Authentication & login failures →MCP server connection issues →

Browse all Claude Code issue topics →