[BUG] Claude Cowork "API Error: Connection error"

Happens to me the same here.
EDIT:
This seems related to Cloudflare's captcha challenge not prompting correctly. Using a VPN triggered the challenge properly, and after completing it, the issue was resolved.

Happens to me the same here. EDIT: This seems related to Cloudflare's captcha challenge not prompting correctly. Using a VPN triggered the challenge properly, and after completing it, the issue was resolved.

I've tried on and off of Cloudflare VPN and get the same result -- I think that I am in a minority of users hitting the a-api.anthropic.com endpoint, which hasn't been whitelisted in the CSP in the app.

In addition to that, same on the Claude website!

Browser console shows CSP violation:
"Refused to connect to https://a-api.anthropic.com/v1/m because it does not appear in the connect-src directive of the Content Security Policy."

Also: "Fetch API cannot load https://a-api.anthropic.com/v1/t due to access control checks."

This is blocking the Cowork feature from making API calls. The domain a-api.anthropic.com needs to be added to the connect-src CSP directive.

Update: Cowork eventually started working, but the underlying issue may still exist.

Findings from log analysis:

The CSP errors blocking a-api.anthropic.com stopped appearing
The successful Cowork session appears to route through the local Claude Code binary (~/Library/Application Support/Claude/claude-code/2.1.5/claude) rather than the web API path
The logs show [CCD] (Claude Code Desktop) handling the working sessions
Theory: There may be two code paths in Cowork:

Web API path → uses a-api.anthropic.com → blocked by CSP bug
Local Claude Code path → uses local binary → works fine
The app may have fallen back to the working path after the web path failed repeatedly, or restarting the app / killing hung tasks triggered the switch.

The CSP bug still exists — a-api.anthropic.com is still not in the connect-src whitelist. Users hitting the web path will still experience failures.

Confirming this issue on latest versions

I'm also experiencing this exact CSP blocking issue.

Environment:

• macOS 26.2 (Build 25C56, arm64)
• Claude Desktop: 1.1.280
• Claude Code SDK: 2.1.9

Logs from ~/Library/Logs/Claude/claude.ai-web.log:
2026-01-16 09:31:20 [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 09:31:20 [error] Fetch API cannot load https://a-api.anthropic.com/v1/m. Refused to connect because it violates the document's Content Security Policy.

Confirmed:

• Network connectivity to a-api.anthropic.com works fine via curl
• Issue only occurs in Cowork (embedded web view), not in Claude Code CLI
• Multiple occurrences across different dates (Jan 15-16)

The fix should be straightforward: add https://a-api.anthropic.com (or https://.anthropic.com) to the CSP connect-src directive.

Same CSP issue affecting Claude Desktop Cowork on macOS
I'm experiencing the identical CSP error in Claude Desktop (not Chrome extension), blocking Cowork functionality.
Environment:

Claude Desktop 1.1.381 (latest)
macOS 26.1 (Tahoe) on Apple M1 Pro
Max subscription

Error from logs (today, 2026-01-18):
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"
What I've tried:

Multiple app versions (1.0.3218 → 1.1.280 → 1.1.381)
Complete uninstall + data wipe + fresh install
Clean network (no VPN, no firewall, no proxy, no MDM)
Verified DNS resolves correctly
Different network locations (Netherlands, Argentina)

I still have this issue

UPDATE: Latest update to 1.1.673 does not fix the issue.

UPDATE 2: Latest update to 1.1.799 also does not fix the issue.

Hey folks, noting that CSP blocks a-api.anthropic.com is a red herring and the actual issue here is not clear. If folks are hitting this can you confirm if:

• Cowork _ever_ successfully made a request on your device
• Do you have any outbound proxy / VPN configuration on your device

Hey folks, noting that CSP blocks a-api.anthropic.com is a red herring and the actual issue here is not clear. If folks are hitting this can you confirm if: Cowork _ever_ successfully made a request on your device Do you have any outbound proxy / VPN configuration on your device

@MarshallOfSound thanks for the reply. Confirming that for me, Cowork has never made a successful request on my devices (have tried two different machines on the same network). Also confirming that I do have proxy / VPN configurations on the device, and have tried every combination. Natively, I use iCloud Private Relay, and have turned it off. I also have WarpVPN that I installed just for the purpose of testing if Claude Cowork was being blocked by my ISP. It doesn't work in every combination of WarpVPN and iCloud Private Relay on/off.

Would love to help troubleshoot more. Anything else I can do to help pinpoint?

Diagnostic Info

Answering @MarshallOfSound's questions:

1. Has Cowork ever successfully made a request on my device? → No, never worked
2. Outbound proxy/VPN configuration? → None

Environment

• macOS: Darwin 25.2.0 (Tahoe)
• Claude Desktop: 1.1.886 (ef5d26)
• Account: Max (20x)
• Chip: Apple Silicon

Verified OK

• ✅ Network connectivity to api.anthropic.com:443 (curl + netcat confirmed)
• ✅ No VPN active (default route via en0, not utun)
• ✅ No system proxy configured (scutil --proxy clean)
• ✅ macOS Firewall allows Claude Helper
• ✅ No Little Snitch / Lulu / network monitors
• ✅ Cleared caches (~/Library/HTTPStorages/ + ~/Library/Caches/) - didn't help

Error Logs (unknown-window.log)

2026-01-24 22:38:43 [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".

Also seeing UUID validation errors:

path.conversation_uuid: Input should be a valid UUID, invalid character: expected [0-9a-fA-F-], found 'l' at 1

Happy to provide additional logs or run diagnostics if needed.

Exact same problem here! Should be easy fix

On Sat, Jan 24, 2026 at 18:42 quentintou @.***> wrote:

quentintou left a comment (anthropics/claude-code#18006) <https://github.com/anthropics/claude-code/issues/18006#issuecomment-3795585456> Diagnostic Info Answering @MarshallOfSound <https://github.com/MarshallOfSound>'s questions: 1. Has Cowork ever successfully made a request on my device? → No, never worked 2. Outbound proxy/VPN configuration? → None Environment - macOS: Darwin 25.2.0 (Tahoe) - Claude Desktop: 1.1.886 (ef5d26) - Account: Max (20x) - Chip: Apple Silicon Verified OK - ✅ Network connectivity to api.anthropic.com:443 (curl + netcat confirmed) - ✅ No VPN active (default route via en0, not utun) - ✅ No system proxy configured (scutil --proxy clean) - ✅ macOS Firewall allows Claude Helper - ✅ No Little Snitch / Lulu / network monitors - ✅ Cleared caches (~/Library/HTTPStorages/ + ~/Library/Caches/) - didn't help Error Logs (unknown-window.log) 2026-01-24 22:38:43 [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". Also seeing UUID validation errors: path.conversation_uuid: Input should be a valid UUID, invalid character: expected [0-9a-fA-F-], found 'l' at 1 Happy to provide additional logs or run diagnostics if needed. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/18006#issuecomment-3795585456>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7YSJGSQ7LG55FRGE4PLVS34IPROBAVCNFSM6AAAAACRS4FVFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJVGU4DKNBVGY> . You are receiving this because you commented.Message ID: @.***>

GitHub Issue #18006 Update

```markdown
## Comprehensive Diagnostic Report (2026-01-26)

I've done extensive troubleshooting with fresh logs and isolated tests. Here's what I've found:

### Environment

• Claude Desktop: 1.1.886
• macOS: 26.2 (Tahoe) on Apple M4 Pro
• Network: Home WiFi with Cloudflare Warp VPN available
• Subscription: Claude Max

### Key Findings

#### 1. The CSP Error is Confirmed as a Red Herring
As @MarshallOfSound noted, the a-api.anthropic.com CSP error is misleading. The real issues are deeper.

#### 2. Two Distinct Failure Modes Discovered

With Warp VPN OFF:
```

Session initialization failed: net::ERR_CONNECTION_RESET
failed_step: 'auth'
error_message: 'net::ERR_CONNECTION_RESET'

``
OAuth fails before the CLI even starts. However, curl from the command line reaches api.anthropic.com` successfully on the same network.

With Warp VPN ON:

• OAuth succeeds
• VM boots successfully (192.168.64.11, network status: CONNECTED)
• Claude CLI spawns inside VM (PID assigned)
• CLI produces zero output and makes zero network requests
• MITM proxy logs show no HTTP traffic from the CLI
• Complete silence after "started PID XXXX"

#### 3. Network Path Analysis

| Test | Warp ON | Warp OFF |
|------|---------|----------|
| curl https://api.anthropic.com | ✅ Works | ✅ Works |
| iPhone Claude app (same WiFi) | ✅ Works | ✅ Works |
| Claude Desktop OAuth | ✅ Works | ❌ ERR_CONNECTION_RESET |
| Cowork CLI in VM | ❌ Hangs silently | ❌ Never starts |

#### 4. Root Cause Hypothesis

The VM uses vmnet (192.168.64.x network) which NATs through the Mac host. Even when Warp VPN is active on the Mac, VM traffic likely bypasses the Warp
tunnel and goes directly through the ISP.

Evidence:

• VM network: gateway=192.168.64.1 guestIP=192.168.64.11
• Warp tunnel: utun4 interface at 172.16.0.2
• These are separate network paths

The CLI inside the VM starts but immediately hangs — no stdout, no stderr, no network requests logged by the MITM proxy. It appears to die or hang during
initialization, possibly during MCP server setup, before ever attempting an API call.

### Logs Excerpt (Warp ON test)

```

2026-01-26 09:03:36 [info] [Spawn:vm] Spawn succeeded
2026/01/26 16:03:36 [process] started PID 2341

^^^ Last log entry. Complete silence after this.

No HTTP requests logged by MITM proxy.

No stdout/stderr from CLI process.

```

### UUID Validation Error (Separate Issue)

Still seeing this in the web UI:
```

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 IDs like local_efcbc620-1e19-4a26-bb8b-7807a148bf5f have the local_` prefix that's being rejected. This appears to be issue #18644.

### Questions for the Team

1. Is the VM's network traffic expected to go through the host's VPN tunnel, or does it intentionally bypass it?
2. Can you add more verbose logging to the CLI startup inside the VM to see where it's hanging?
3. Is there a way to test if the VM can reach api.anthropic.com directly?

### What I've Tried

• ✅ Cleared all caches (~/Library/HTTPStorages/, ~/Library/Caches/)
• ✅ Cleared local-agent-mode-sessions
• ✅ Fresh logs with clean state
• ✅ Tested with Warp ON and OFF
• ✅ Verified raw network connectivity via curl
• ✅ Multiple Claude Desktop versions (1.0.3218 → 1.1.886)

Cowork has never worked on my machine since launch.

I'm having this issue, too. It was working fine for me with the same setup (MacOS latest, no VPN, no firewalls), same Starlink internet.

API Error: Connection error.

Any other thoughts or ideas to debug?

Hey folks, pretty sure we've got an inbound fix for this that a few of you folks who've sent in feedback tested out to validate for us (Thanks a lot for that). We should be sending out a release with a fix this ASAP week, I'll update this thread when that goes out.

Most of the time this issue is caused by custom VPN or DNS configurations on your machine, if disabling those doesn't help the fix release likely still will. We're working on it 👍

Hey folks, pretty sure we've got an inbound fix for this that a few of you folks who've sent in feedback tested out to validate for us (Thanks a lot for that). We should be sending out a release with a fix this ASAP week, I'll update this thread when that goes out. Most of the time this issue is caused by custom VPN or DNS configurations on your machine, if disabling those doesn't help the fix release likely still will. We're working on it 👍

Thank you! That's great!

In the meantime, turn off "Use Tailscale DNS Settings" if that's the layer you use. I'm sure most VPN servers have similar options, but it was Tailscale DNS for me.

Thanks for the update. Looking forward to testing again.

Hey folks, we've fixed the majority of these errors in v1.1.1093 (released an hour ago). Ensure you're up to date and then you should be good to go.

Any issues please thread them below (and ensure you submit feedback with logs so I can help track down any straggling issues)

Hey folks, we've fixed the majority of these errors in v1.1.1093 (released an hour ago). Ensure you're up to date and then you should be good to go. Any issues please thread them below (and ensure you submit feedback with logs so I can help track down any straggling issues)

Working for me! Thanks!

Seems to work for me as well. I had no VPN or DNS configurations so none of the other fixes worked, but I'm no longer getting this error. Thanks for fixing! Will let you know if anything else comes up as I dig into cowork for the first time.

Workspace is getting regenerated. Waiting...

<img width="529" height="97" alt="Image" src="https://github.com/user-attachments/assets/21b5d175-54e7-4964-bcb8-fb9fd046ee0a" />

It restarted the environment a couple more times, and we're up and running! Good work. Thanks for the quick turnaround. Excited to continue playing with this.

This is now working for me aswell!

working for me thank you!!

Same!

On Wed, Jan 28, 2026 at 14:56 aweilerffp @.***> wrote:

aweilerffp left a comment (anthropics/claude-code#18006) <https://github.com/anthropics/claude-code/issues/18006#issuecomment-3812890702> working for me thank you!! — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/18006#issuecomment-3812890702>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7YSJGTWKX6O63KDVAWXSLD4JDZ3JAVCNFSM6AAAAACRS4FVFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJSHA4TANZQGI> . You are receiving this because you commented.Message ID: @.***>

Still experiencing this issue on v1.1.1520 (Jan 30, 2026).

macOS, no VPN or custom DNS
Updated this morning, tried full quit/restart multiple times
Chat tab works fine, only Cowork fails

Log shows the same CSP error:
Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive
Happy to provide full logs or additional info if helpful.

Try updating your dns ip in wifi settings to 8.8.8.8 or 1.1.1.1 (cloud flare and google) that’s what did it for me

Still experiencing this issue on v1.1.1520 (Jan 30, 2026). macOS, no VPN or custom DNS Updated this morning, tried full quit/restart multiple times Chat tab works fine, only Cowork fails Log shows the same CSP error: Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive Happy to provide full logs or additional info if helpful.

Try updating your dns ip in wifi settings to 8.8.8.8 or 1.1.1.1 (cloud flare and google) that’s what did it for me > Still experiencing this issue on v1.1.1520 (Jan 30, 2026). > macOS, no VPN or custom DNS Updated this morning, tried full quit/restart multiple times Chat tab works fine, only Cowork fails > Log shows the same CSP error: Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive Happy to provide full logs or additional info if helpful.

Unfortunately the issue persists.. thank you for the tip though!

I'm having the very same issue. Tried everything, and it's not working. How do I fix this? I was in the middle of a project which is due in 25 minutes... this couldn't have happened at a worse time.

I'm having the very same issue. Tried everything, and it's not working. How do I fix this? I was in the middle of a project which is due in 25 minutes... this couldn't have happened at a worse time.

I fixed mine this morning finally. I asked claude to search the internet to find ways to troubleshoot this and it came back with a solution. it gave me three scripts to enter into terminal that deleted my Virtual Machine causing the desktop app to redownload a new version of the VM. i pasted the three short scripts into terminal, quit claude, then waited 30 seconds and tried to start it up again and it worked. I do not have the three scripts it generated for me anymore but I bet if you ask claude it will give them to you. Just screenshot the error message and tell claude opus your situation.

> I'm having the very same issue. Tried everything, and it's not working. How do I fix this? I was in the middle of a project which is due in 25 minutes... this couldn't have happened at a worse time. I fixed mine this morning finally. I asked claude to search the internet to find ways to troubleshoot this and it came back with a solution. it gave me three scripts to enter into terminal that deleted my Virtual Machine causing the desktop app to redownload a new version of the VM. i pasted the three short scripts into terminal, quit claude, then waited 30 seconds and tried to start it up again and it worked. I do not have the three scripts it generated for me anymore but I bet if you ask claude it will give them to you. Just screenshot the error message and tell claude opus your situation.

Thanks. I don't have a virtual machine... I think it's a network/VPN type issue. Hope it can be fixed.

Is this related or unrelated from the email from John from Anthripic today?:

"Hi there,

We're currently aware of an issue affecting users signing in to the Claude Desktop app. Our team is actively investigating and working to resolve this as quickly as possible.
​

In the meantime, you should still be able to access Claude through our web browser at Claude.ai while we work on the fix.
​

We appreciate your patience and apologize for any disruption this may have caused. We'll follow up once the issue has been resolved.

Thank you for your continued patience.
​

Kind regards,
Anthropic Support"

Unfortunately the issue persists

Still persist in the latest app update.

Still persisting Claude 1.1.2321

#18644 was closed and discussion redirected to other threads (including #18474 / #18006), but I’m still hitting a UUID validation failure on Claude Desktop 1.1.1890 (af393c), macOS 26.2.

Posting the screenshot and exact error text verbatim below to make it easy to grep/search in issues and logs.

<img width="500" height="111" alt="Image" src="https://github.com/user-attachments/assets/44a44e9a-8d73-4d36-b8c2-c7e0240458f5" />

parent_message_uuid: Input should be a valid UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-fA-F-], found `n` at 1

This occurs intermittently during normal Chat use (no config changes), and when it happens it repeats until a request eventually succeeds. The only workaround I’ve found is to keep retrying without changing anything.

VPN is inactive. Since this is parent_message_uuid (and not the local_-prefixed conversation ID from #18644), it may be a separate bug, but the symptom pattern feels similar.

@MarshallOfSound — flagging this since you redirected the earlier threads; this looks like a different UUID validation path than the original local_ issue.

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.