[BUG] Claude Desktop Code/Cowork mode returns 403 "Request not allowed" while CLI and Chat work fine

Status Fixed / completed

Reported on v2.1.62

Maintainer reply None cached

Activity 9 comments · opened Mar 10, 2026 · closed Apr 21, 2026

Bug Description

Claude Desktop's Code mode and Cowork mode consistently return 403 {"error":{"type":"forbidden","message":"Request not allowed"}}, while all other methods of using Claude work perfectly:

| Environment | Status |
|-------------|--------|
| Claude Desktop Chat | ✅ Works |
| Claude Desktop Code | ❌ 403 Forbidden |
| Claude Desktop Cowork | ❌ 403 Forbidden |
| claude.ai (web browser) | ✅ Works |
| Claude Code CLI (terminal) | ✅ Works |
| Claude Code in VSCode | ✅ Works |

Key Details

Subscription: Max plan
Account email: qinwanjiede@gmail.com
Org ID: 99948e90-83d1-437b-8d89-9852170009d1
Claude Desktop version: 1.1.5749
Claude Code CLI version: 2.1.62
macOS version: 26.3 (Build 25D125)
Architecture: Apple Silicon (arm64)

OAuth Token Works, API Rejects

The OAuth token exchange succeeds — the token is obtained and cached. But when Code/Cowork uses this token to call the API, it gets rejected:

[oauth] obtained new token for orgId=99948e90-83d1-437b-8d89-9852170009d1, caching
...
[APIError] Intermediate SDK error "authentication_failed" for session local_xxx
  error_message: 'Failed to authenticate. API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}}'

Cowork VM Behavior

The Cowork VM starts successfully, API reachability check passes, OAuth token is approved, but Claude Code inside the VM exits within ~2-3 seconds:

[VM] API reachability: REACHABLE
[Spawn:vm] OAuth token approved with MITM proxy
[Spawn:vm] Spawn succeeded in 235ms
[Process] Exited, code=0, signal=null, duration=3099ms

CLI Auth Status (same account, works fine)

{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "apiProvider": "firstParty",
  "email": "qinwanjiede@gmail.com",
  "orgId": "99948e90-83d1-437b-8d89-9852170009d1",
  "subscriptionType": "max"
}

What I've Tried

✅ Signed out and back in from Claude Desktop
✅ Cleared auth cache (Local Storage, Session Storage, Cookies, HTTPStorages)
✅ Reinstalled Claude Desktop
✅ Set proxy env vars via launchctl setenv
✅ Launched with explicit HTTP_PROXY/HTTPS_PROXY env vars
✅ Tested with TUN mode on/off
✅ Verified network connectivity — api.anthropic.com is reachable and returns proper responses
✅ Confirmed the same account works perfectly via CLI and web

Expected Behavior

Code and Cowork modes should work the same as Chat mode and CLI, since the account is authenticated and has a Max subscription.

Request

Could you please check if there is a server-side restriction on the Code/Cowork feature for this account (org ID 99948e90-83d1-437b-8d89-9852170009d1)? The 403 appears to be a server-side policy rejection since the OAuth token is valid but the API returns forbidden instead of authentication_error.

View original on GitHub ↗

9 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

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

qinwanjie · 5 months ago

This is not a duplicate of the referenced issues.

#24485: That was an intermittent token issue that self-healed. My issue has persisted for weeks and never self-heals.
#28486: That is about MCP connector auth, not the core Code/Cowork API access.
#30318: I have already tried every solution listed — launchctl setenv, explicit HTTP_PROXY/HTTPS_PROXY, TUN mode, system proxy. None fixed it.

What makes this different:

Claude Code CLI works perfectly on the same machine, same account, same network — this is NOT a network/proxy issue
Chat mode in Desktop works — the app CAN connect through the proxy
OAuth token is successfully obtained but API returns forbidden (not authentication_error) — suggesting a server-side policy restriction on Desktop Code/Cowork
Consistently reproducible across restarts, re-logins, cache clears, network configs

This appears to be a server-side authorization issue. Could someone please check if there is a restriction on org 99948e90-83d1-437b-8d89-9852170009d1?

liuyuhanalex · 5 months ago

I encountered the same issue. The difference is that Claude Code in my Claude Desktop works fine — only Cowork keeps hitting the 403 error. I've already enabled TUN mode on my VPN, so it shouldn't be a network issue. I also tried all the solutions mentioned in this issue — Fix: Claude Code 403 "Request not allowed" on macOS with Proxy/VPN (China & Region-restricted Areas) #30318 — but the problem still isn't resolved.

liuyuhanalex · 5 months ago

I resolved this issue. The root cause was that TUN mode in my proxy tool (Clash Verge) appeared to be enabled in the UI, but was not actually functioning due to insufficient system permissions (operation not permitted). After installing the Service Mode to grant proper privileges, TUN mode started correctly and Cowork no longer returns 403.
For example, I use clash

Check Clash logs for TUN startup status (look for any errors)

cat ~/Library/Application\ Support/io.github.clash-verge-rev.clash-verge-rev/logs/*.log | grep -i "tun" | tail -10

Check if DNS has been taken over by Clash (should show 223.6.6.6 if TUN is active)

scutil --dns | grep nameserver | head -5

Check routing table to see if default traffic is going through utun

netstat -rn | grep default

VariianWrynn · 5 months ago

nb兄弟，我搞了半天没搞懂

I resolved this issue. The root cause was that TUN mode in my proxy tool (Clash Verge) appeared to be enabled in the UI, but was not actually functioning due to insufficient system permissions (operation not permitted). After installing the Service Mode to grant proper privileges, TUN mode started correctly and Cowork no longer returns 403. For example, I use clash 1. Check Clash logs for TUN startup status (look for any errors) cat ~/Library/Application\ Support/io.github.clash-verge-rev.clash-verge-rev/logs/*.log | grep -i "tun" | tail -10 2. Check if DNS has been taken over by Clash (should show 223.6.6.6 if TUN is active) scutil --dns | grep nameserver | head -5 3. Check routing table to see if default traffic is going through utun netstat -rn | grep default <img alt="Image" width="551" height="187" src="https://private-user-images.githubusercontent.com/30294295/562788829-bc45d465-6e39-418b-850f-9c51b6057b09.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzM1ODA2OTIsIm5iZiI6MTc3MzU4MDM5MiwicGF0aCI6Ii8zMDI5NDI5NS81NjI3ODg4MjktYmM0NWQ0NjUtNmUzOS00MThiLTg1MGYtOWM1MWI2MDU3YjA5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzE1VDEzMTMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWIxM2YyMWJlNTNlYWE4MjIzZjg3ZmQ2ODFjNTUyYTQ1NWUwMWQ1YzJkMDkxM2JhZjY1MmUxYzI5Yjg5ZjA0MzgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.vsmFA0Z-9h69F7DJKoGRdEvkwlPdJUS2ta6DkjkkmWU">

handsome-rich · 5 months ago

请问楼主解决了吗

nhducminh · 5 months ago

Same issue. Pro plan, Windows, Docker running.
Chat and Cowork work fine, only Code tab returns 403 "Invalid or inactive API key".
Claude Code CLI works perfectly with the same account. Desktop app version: [4.41.2 (191736)].
Tried sign out/in, cleared cache — no change.

Babyjesusc · 4 months ago

Same issue. Existing Projects work fine, only newly created Projects trigger 403 error. Max subscriber, macOS, Beijing.

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