›_ Claude Code Issues
Claude Code Issues / #18474

[BUG] Claude Cowork stuck on 'sending request'

Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 12 comments · opened Jan 16, 2026 · closed Jan 27, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Cowork gets permanently stuck on "sending request" after the Statsig client encounters network connectivity issues. Even after network is restored, the Statsig client remains in a broken state and cannot recover without manually clearing app cache.

Key symptoms:

  • Regular Claude chat works fine
  • Cowork specifically stuck on "sending request"
  • Network connections are established but requests hang

Environment

  • Platform: macOS (Tahoe)
  • Claude Desktop Version: Latest (January 2026)
  • Subscription: Claude Max

Root Cause Analysis

From ~/Library/Logs/Claude/claude.ai-web.log:

WARN  [Statsig] useFeatureGate hook failed to find a valid StatsigClient for gate 'asset_prefetch_enabled'.
ERROR [Statsig] Failed to parse EvaluationResponse
ERROR [REACT_QUERY_CLIENT] QueryClient error: Error: Invalid authorization

The Statsig client (feature flag system) gets into a corrupted state when statsig.anthropic.com is temporarily unreachable. Once corrupted, the client cannot recover even after connectivity is restored.

Steps to Reproduce

  1. Use Claude Desktop with a VPN that blocks or interferes with statsig.anthropic.com (e.g., Mullvad VPN via Tailscale exit node)
  2. Attempt to use Cowork - it will fail/hang
  3. Fix network connectivity (disable VPN or add split tunnel routes)
  4. Attempt Cowork again - still stuck on "sending request"
  5. Regular chat continues to work fine

Expected Behavior

  • Statsig client should gracefully handle network failures
  • Statsig client should automatically retry/recover when network is restored
  • Cowork should not permanently break due to transient network issues

Actual Behavior

  • Statsig client fails to parse response and enters permanent error state
  • Cached state becomes corrupted
  • Only fix is to manually delete cache directories:
  • ~/Library/HTTPStorages/com.anthropic.claudefordesktop/
  • ~/Library/Caches/com.anthropic.claudefordesktop/

Suggested Fix

  1. Add retry logic with exponential backoff to Statsig client initialization
  2. Implement cache invalidation when Statsig responses fail to parse
  3. Add a "reset" or "clear cache" option in the app UI for users
  4. Consider graceful degradation - allow Cowork to function with cached/default feature flags if Statsig is unreachable

Workaround

Clear the cache directories and restart the app:

rm -rf ~/Library/HTTPStorages/com.anthropic.claudefordesktop/
rm -rf ~/Library/Caches/com.anthropic.claudefordesktop/

Then relaunch Claude Desktop.

View original on GitHub ↗

12 Comments

github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/12792
  2. https://github.com/anthropics/claude-code/issues/16590
  3. https://github.com/anthropics/claude-code/issues/11220

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

nathanschram · 7 months ago

Update: Additional Bug Found - CSP Blocking API Endpoint

After further investigation (with VPN completely disabled and all traffic going direct), we found a second bug that is also blocking Cowork:

Content Security Policy Violation

From ~/Library/Logs/Claude/claude.ai-web.log:

2026-01-16 15:16:25 [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-16 15:16:25 [error] Fetch API cannot load https://a-api.anthropic.com/v1/m. Refused to connect because it violates the document's Content Security Policy.

Issue

The app is trying to connect to a-api.anthropic.com but this domain is not included in the app's own CSP connect-src directive.

The CSP only allows:

  • a-cdn.anthropic.com (CDN)
  • Various analytics domains (segment.io, google.com, facebook.com, etc.)

But NOT:

  • a-api.anthropic.com (the API endpoint the app is actually trying to use)

Environment

  • Claude Desktop version: 1.0.3218
  • Platform: macOS

This appears to be a separate bug from the Statsig issue

Even after:

  1. Completely disabling VPN
  2. Fresh reinstall of Claude Desktop
  3. Clearing all cache directories

Cowork remains stuck because the app cannot connect to its own API endpoint due to CSP restrictions.

nathanschram · 7 months ago

Not a duplicate - distinct issues identified

This issue is not a duplicate of the linked issues:

| Linked Issue | Their Problem | Our Problem |
|-------------|---------------|-------------|
| #12792 | Web interface stuck loading | Desktop app Cowork stuck |
| #16590 | CLI randomly freezes 5 min | Cowork permanently stuck |
| #11220 | Statsig proxy settings | Related but different - we found Statsig client corruption + CSP bug |

Our issue identifies TWO distinct bugs:

Bug 1: Statsig client doesn't recover from network issues

  • Once Statsig fails (e.g., due to VPN), the client enters permanent error state
  • Clearing cache is the only fix
  • Root cause: No retry/recovery logic when EvaluationResponse fails to parse

Bug 2: CSP blocks a-api.anthropic.com (NEW - not in any linked issue)

  • App's Content Security Policy doesn't include its own API endpoint
  • Error: Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive
  • This is a bug in the app itself, not network-related

While #11220 is tangentially related (Statsig + network), our findings provide:

  1. Specific root cause analysis with log evidence
  2. Discovery of the CSP bug (completely new)
  3. Detailed reproduction steps and workarounds

Please keep this issue open for proper triage.

jefftropeano · 7 months ago
## Update: Additional Bug Found - CSP Blocking API Endpoint After further investigation (with VPN completely disabled and all traffic going direct), we found a second bug that is also blocking Cowork: ### Content Security Policy Violation From ~/Library/Logs/Claude/claude.ai-web.log: `` 2026-01-16 15:16:25 [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-16 15:16:25 [error] Fetch API cannot load https://a-api.anthropic.com/v1/m. Refused to connect because it violates the document's Content Security Policy. ` ### Issue The app is trying to connect to a-api.anthropic.com but this domain is **not included in the app's own CSP connect-src directive**. The CSP only allows: * a-cdn.anthropic.com (CDN) * Various analytics domains (segment.io, google.com, facebook.com, etc.) But NOT: * a-api.anthropic.com` (the API endpoint the app is actually trying to use) ### Environment Claude Desktop version: 1.0.3218 Platform: macOS ### This appears to be a separate bug from the Statsig issue Even after: 1. Completely disabling VPN 2. Fresh reinstall of Claude Desktop 3. Clearing all cache directories Cowork remains stuck because the app cannot connect to its own API endpoint due to CSP restrictions.

This is also reported here: https://github.com/anthropics/claude-code/issues/18006#issuecomment-3746808098

I've encountered the same, preventing Claude Cowork from working entirely.

joenoon · 7 months ago

I've had claude code itself analyze my debug logs and extract what it thinks are the relevant logs:

Environment:

  • macOS 26.2.0 (Darwin kernel 25.2.0), M3 Max
  • Claude Desktop: v1.1.799
  • SDK: v2.1.15
  • Cowork VM

Issue: "Sending request" hangs, then eventually displays "API Error: Connection error"

Root cause appears to be VM networking:

  • VM boots and connects successfully
  • OAuth token approved
  • Session initialized
  • FAILS when SDK makes first HTTP request to api.anthropic.com

SDK debug logs show (e.g. sdk-debug-01-local_b3a041d1-8394-4593-81ca-6c0be9e6ed00.txt):

  Error: Connection error.
    at makeRequest (/$bunfs/root/claude:900:4548)
    
  countTokensWithFallback: API returned null, trying haiku fallback (18 tools)
  countTokensWithFallback: haiku fallback failed: Connection error.
  
  1P event logging: 25 events failed to export

VM can connect to host but cannot make outbound HTTP requests to Anthropic API.

No VPN/proxy in use. Network bridges visible: en0, bridge100-102

It also noted:

The issue appears to be with the Cowork VM's ability to reach external APIs, despite the VM itself networking being "CONNECTED". This could be a routing issue, firewall, or DNS problem within the VM environment.
joenoon · 7 months ago

Fix: dnsmasq interfering with Cowork VM networking

I had dnsmasq running on my Mac (likely from an old local dev setup I no longer use or remember why).

My config was minimal:

address=/.localhost/127.0.0.1 port=53

The problem: without listen-address and bind-interfaces specified, dnsmasq binds to all interfaces — including the bridge interfaces that Cowork's VM uses for networking. This was intercepting DNS queries from the VM.

Solution:

sudo brew services stop dnsmasq

Cowork immediately started working after that.

If you need to keep dnsmasq running for local dev, restrict it to localhost only:

listen-address=127.0.0.1 bind-interfaces

You can check if dnsmasq is running with sudo lsof -i :53.

Thank you to https://github.com/anthropics/claude-code/issues/18854#issuecomment-3793691280 for saying dnsmasq and immediately a lightbulb went off!

95 · 7 months ago
sudo lsof -i :53

I am on Claude Desktop 1.1.886 and Mac M3 version 26.2.0. Having this issue without dnsmasq.

phronese · 7 months ago

Same symptoms: Cowork stuck on "sending request", regular chat works fine.

But for me clearing caches and even a complete reinstall doesn't fix it.

Additional findings:

  • VM boots and spawns process successfully (logs show Spawn succeeded)
  • Process runs but produces zero output - API requests from inside VM seem to hang silently
  • All MCP servers fail: MCP error -32000: Connection closed
  • Had a NextDNS encrypted DNS profile installed (removed it, no change)

Environment: macOS 26.2, M3 Pro

This might be a more severe variant, possibly specific to macOS 26.2's Virtualization framework
changes affecting VM networking.

phenggeler · 7 months ago

Confirmed: Same issue on macOS 26.2 + v1.1.886

Environment:

  • macOS: 26.2.0 (Darwin kernel 25.2.0), M4 Pro
  • Claude Desktop: v1.1.886
  • Subscription: Claude Max

Symptoms:

  • Cowork stuck on "Sending request..."
  • Regular Chat works fine
  • Reproduced immediately after fresh install

Root Cause Confirmed:
Hit all three bugs mentioned in this thread:

  1. ✅ CSP blocking - Fixed by cache clear

Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates
the following Content Security Policy directive

  1. ✅ Statsig corruption - Fixed by cache clear

ERROR [Statsig] Failed to parse EvaluationResponse

  1. ❌ local_ UUID prefix (#18644) - Still broken after cache clear

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

Session ID generated:
local_6936b625-7a7b-4025-a62d-c4e2e6b70c0d

Workaround Attempted:
```bash
rm -rf ~/Library/HTTPStorages/com.anthropic.claudefordesktop/
rm -rf ~/Library/Caches/com.anthropic.claudefordesktop/

This fixed CSP + Statsig bugs, but Cowork still fails due to the UUID validation issue.

Additional Context:

  • VM boots successfully, networking connected, OAuth approved
  • Process spawns successfully (confirmed in cowork_vm_node.log)
  • Failure occurs when API rejects local_ prefixed conversation UUID
c0webster · 7 months ago

Chiming in to say that I had this error and fixed it by removing Mullvad VPN from my computer. It wasn't even running, but I guess something in Mullvad's config broke the Claude Cowork setup.

MarshallOfSound · 7 months ago

Merging into #18006, fix should be coming soon for these fun networking configurations 😄

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

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Authentication & login failures, Hooks & automation, Crashes, hangs & freezes

Browse all Claude Code issue topics →