[BUG] Cowork incompatible with VPN - Hyper-V NAT routing prevents VM from reaching Claude API

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment:

OS: Windows 10
Claude Desktop: v1.1.2998.0 (Microsoft Store version)
VPN: Windscribe (likely affects all VPNs)
Cowork VM Network: vEthernet (cowork-vm-nat) using NAT mode

Summary:

Cowork's Hyper-V NAT networking layer is fundamentally incompatible with VPN software. The VM cannot reach api.anthropic.com when a VPN is active, forcing users to choose between using Cowork or maintaining VPN protection.

Issue:

When any VPN is active, the Cowork VM fails to reach Claude's API with these errors:

API Error: Unable to connect to API (ECONNRESET)
"Taking longer than expected to reach the Claude API" → timeout
"Failed to start Claude's workspace - Can't reach the Claude API from Claude's workspace"

What works:

✅ Cowork works perfectly when VPN is disconnected
✅ Regular Chat mode works with VPN connected
✅ Host computer can reach api.anthropic.com with VPN active

What fails:

❌ Cowork VM cannot reach Claude API through the VPN tunnel
❌ Cowork VM cannot reach Claude API even when VPN split tunnel is configured
❌ Cowork VM routing ignores host-level routing table overrides

Root Cause:

The Hyper-V NAT layer (vEthernet (cowork-vm-nat)) caches routing decisions at VM creation time and does not:

Respect VPN split tunnel exclusions
Honor Windows routing table entries (even persistent routes)
Update when network adapter metrics are changed
Refresh when Hyper-V Host Network Service is restarted

Traffic from the VM is routed through the VPN tunnel despite all configuration attempts to exclude it.

Extensive Troubleshooting (with VPN vendor support):

Working with Windscribe VPN support, the following were tested:

1. VPN Split Tunnel Configuration ❌

Configuration:

Mode: Exclusive (bypass VPN for specified apps/domains)
Apps excluded: claude.exe, cowork-svc.exe
Domains excluded: api.anthropic.com, claude.ai, statsig.anthropic.com, cdn.anthropic.com, assets.anthropic.com
Windscribe firewall: Disabled
R.O.B.E.R.T. (DNS blocking): Configured to allow Claude domains

Result: VM traffic still routed through VPN tunnel

1. Network Adapter Metrics (Priority) ❌

Configuration:
powershell

Wi-Fi: metric 5 (highest priority - physical connection)
WindscribeWireguard: metric 10 (VPN tunnel with split rules)
vEthernet (cowork-vm-nat): metric 15 (Cowork VM)

Purpose: Ensure VPN split tunnel rules are evaluated before VM routing decisions

Result: No improvement - VM ignores metric priorities

1. Persistent Routes (Manual Routing Table) ❌

Configuration: Added persistent routes forcing Claude IPs through Wi-Fi gateway:
powershell

route -p add 160.79.104.10 mask 255.255.255.255 192.168.0.1 metric 5 # api.anthropic.com
route -p add 34.36.57.103 mask 255.255.255.255 192.168.0.1 metric 5 # statsig.anthropic.com
route -p add 13.33.153.35 mask 255.255.255.255 192.168.0.1 metric 5 # assets.anthropic.com

Purpose: Force specific Claude IPs to bypass VPN at Windows routing table level

Result: Partial improvement only

Initial connection sometimes succeeds
Response streaming still fails/times out
Unreliable and intermittent

1. Hyper-V Host Network Service Restart ❌

Configuration:
powershell

net stop hns
net start hns

**Purpose:** Force Hyper-V to rebuild NAT translation table with current routing rules

**Result:** No improvement

### 5. Security Software ❌
**Configuration:**
- Windows Firewall: Temporarily disabled
- Windscribe firewall: Disabled
- Acronis Active Protection: Exclusions added for Claude and VM paths
- NetLimiter: No blocking rules configured

**Result:** No improvement

---

**Diagnostic Logs:**

With VPN connected:

[VM] Network status: CONNECTED
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable

With VPN disconnected:

[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[VM:start] Startup complete

---

**Expert Assessment (Windscribe VPN Support):**

According to VPN vendor support, the only reliable solution is to use an **External vSwitch** instead of NAT mode. This would:
- Give the VM its own MAC address on the physical LAN
- Allow VPN split tunnel rules to apply correctly to VM traffic
- Bypass the problematic NAT translation caching layer

**However:** Cowork's VM is automatically managed by Claude Desktop and cannot be manually reconfigured to use External vSwitch without breaking Cowork entirely.



### What Should Happen?

**Proposed Solutions:**

**Option 1 (Ideal):** Add External vSwitch Support
- Add a Settings option to use External virtual switch instead of NAT
- VM would operate on the same network as the host
- VPN split tunnel and routing rules would work correctly
- Users could enable this for VPN compatibility

**Option 2:** VM-Level Routing Configuration
- Configure routes inside the Cowork VM itself
- Bypass reliance on host NAT translation
- Force Claude API traffic through specific gateway

**Option 3:** VPN Detection and Guidance
- Detect VPN during Cowork startup
- Display clear warning about VPN incompatibility
- Offer to temporarily disable VPN for the session
- Document which VPNs are compatible/incompatible

**Option 4:** Documentation
- Clearly document VPN limitations
- Provide official configuration guidance
- Set proper user expectations



### Error Messages/Logs

```shell

Steps to Reproduce

Run Claude Cowork on Windows with WIndscribe VPN

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Version 1.1.2998 (1f1d4d)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Impact:

Many users require VPNs for:

• Privacy and security (personal users)
• Corporate security policies (enterprise users)
• Remote work requirements
• Regulatory compliance

Cowork currently forces users to choose between productivity (Cowork) and security (VPN). This is unacceptable for:

• Enterprise deployments
• Security-conscious professionals
• Remote workers
• Users in regions requiring VPN access

---

Current Workaround:

Disable VPN when using Cowork. This is not viable for users with security requirements or corporate policies.

---

Technical Details:

Network configuration snapshots, complete diagnostic logs, and routing table outputs available upon request.