[BUG] Cowork VM fails to reach API on corporate/institutional network

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?

Cowork's Linux VM (Apple Virtualization.framework) consistently fails to make API calls when connected to a corporate/institutional network. The VM sits on a private 192.168.64.0/24 subnet via a macOS vmnet bridge interface. On home/consumer networks, macOS handles routing transparently. On corporate networks, two problems cause the VM's API calls to fail:

1. No NAT for the VM's private subnet: The 192.168.64.x source addresses are not routable on the corporate network. Return traffic from api.anthropic.com never reaches the VM.
2. No MTU/MSS clamping: The VM's default MTU (1500) can exceed what the network path supports. The coworkd reachability check (a small HTTP request) succeeds, but the actual Claude API payload (~47KB) gets fragmented and silently dropped, resulting in ECONNRESET.

This creates a confusing situation where coworkd logs report API reachability: REACHABLE but the CLI process inside the VM hangs indefinitely, producing no output.

Cascading frontend failure

When the CLI's API call fails, the Claude Desktop frontend falls back to creating a local_-prefixed session ID (e.g., local_eb9433a4-3992-408d-889b-4520e9b5254f). When the app later tries to sync this with Anthropic's servers, the API rejects it because local_ is not a valid UUID prefix. This creates a retry loop of queue-operation warnings and UUID validation errors. (Related: #18644)

Additional issue: bridge interface name changes between reboots

The bridge interface assigned to the Cowork VM (bridge100, bridge101, bridge102, etc.) changes between reboots and VM restarts. Any manual workaround referencing a specific bridge interface name breaks when this changes.

Network Diagnostics (ruling out corporate firewall/proxy)

The following were confirmed on the corporate network:

• curl https://api.anthropic.com — fast, works fine from the host
• TLS certificate issuer: Let's Encrypt (no SSL inspection)
• No web proxy configured (networksetup -getwebproxy Wi-Fi → Enabled: No)
• No MDM/configuration profiles installed
• FortiClient installed but no active VPN tunnel (no IPv4 on utun interfaces)
• DNS resolution works from 192.168.64.1 via dnsmasq

The problem is purely that the VM's private subnet traffic isn't being NATted through the host's network interface.

What Should Happen?

Cowork's VM networking layer should handle NAT and MTU/MSS clamping automatically so the VM can reach the API on any network where the host Mac can reach it

Suggested Fix

The VM networking layer should:

1. NAT traffic from 192.168.64.0/24 through the host's active network interface by default
2. Apply MSS clamping to prevent large packet fragmentation
3. Handle bridge interface name changes gracefully (use subnet-based rules rather than interface names)

Error Messages/Logs

**From `cowork_vm_node.log` — reachability passes but CLI hangs:**

[VM] API reachability: REACHABLE
[VM:start] Startup complete, total time: 5289ms
[Spawn:create] id=401fb9dd name=inspiring-lucid-hypatia cmd=/usr/local/bin/claude
[Process:401fb9dd] Spawn confirmed, flushing 2 buffered stdin chunks
[Spawn:vm] id=401fb9dd Spawn succeeded in 44ms
# No further output — CLI hangs making API call


**From Claude Desktop UI:**

API Error: Unable to connect to API (ECONNRESET)


**From `main.log` — UUID validation errors:**

[REACT_QUERY_CLIENT] QueryClient error: Error: 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


**From `main.log` — repeated queue-operation warnings:**

[LOCAL_SESSION] unknown sdk message type: queue-operation

Steps to Reproduce

1. Connect Mac to a corporate/institutional network (not a home consumer router)
2. Open Claude Desktop
3. Navigate to Cowork tab
4. Send any message
5. Observe "Working on it..." indefinitely, then ECONNRESET
6. Confirm the VM's coworkd logs show API reachability: REACHABLE despite failure

Key diagnostic: The host Mac can reach api.anthropic.com fine (curl works instantly). Only the VM's traffic fails.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.1.4498

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround

Manual pfctl NAT and MSS clamping resolves the issue:

# Find the current Cowork bridge interface
ifconfig | grep -B1 "192.168.64"

# Enable pfctl and apply rules (replace bridge100 with your bridge)
sudo pfctl -e
sudo pfctl -a com.apple/vm-nat -f - <<'EOF'
scrub on bridge100 all max-mss 1200 fragment reassemble
scrub on en0 all max-mss 1200 fragment reassemble
nat on en0 from 192.168.64.0/24 to any -> (en0)
EOF

Note: The bridge interface name changes between reboots, so this must be reapplied with the correct interface name each time.

Environment

• Platform: macOS 26 (Tahoe), Apple Silicon
• Claude Desktop: Latest version (as of Feb 2026)
• Network: Institutional network (Cold Spring Harbor Laboratory), no proxy, no SSL inspection
• VPN: FortiClient installed, no active tunnel
• VM SDK: 2.1.51