[BUG]

Resolved 💬 1 comment Opened Apr 16, 2026 by wrkk112 Closed May 26, 2026

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?

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?

Cowork VM fails to reach Claude API when GlobalProtect VPN is active (DNS resolution timeout)

Related issues:

  • #25513 — Cowork incompatible with VPN / NAT routing
  • #39142 — Network status NOT_CONNECTED even when API reachability REACHABLE

Environment

  • macOS
  • Claude Desktop / Cowork
  • GlobalProtect VPN (active during reproduction)
  • Wi-Fi (en0) as primary network interface

Summary

Cowork fails to start whenever GlobalProtect VPN is active. Disabling GlobalProtect resolves the issue immediately. The root cause appears to be that the Cowork VM's internal DNS server (172.16.10.1) cannot resolve api.anthropic.com when GlobalProtect intercepts outbound traffic.

Key Evidence

From coworkd.log:

[coworkd] configuring static IP on enp0s1: 172.16.10.3/24 gateway=172.16.10.1 dns=172.16.10.1
[coworkd] IPv4 route not yet available, emitting NOT_CONNECTED
error_message: 'API Error: 587 {"error":"coworkd_upstream_failed","category":"dns_failure","detail":"dial tcp: lookup api.anthropic.com on 172.16.10.3:53: read udp 172.16.10.3:58905->172.16.10.1:53: i/o timeout"}'

From cowork_vm_swift.log:

[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE

With GlobalProtect disabled:

[VM] API reachability: REACHABLE  ← works immediately

Root Cause Analysis

The Cowork VM uses Apple Virtualization.framework with gvisor user-mode networking. The VM's DNS is hardcoded to its internal gateway 172.16.10.1. When GlobalProtect is active, it intercepts DNS queries from the host but does not handle traffic from the VM's virtual network interface (bridge0 with members en1/en2/en3), causing DNS resolution for api.anthropic.com to time out inside the VM.

macOS-level routing (sudo route add) does not help because the VM maintains its own independent network stack.

What Should Happen?

What Should Happen?

Cowork should either:

  1. Use a fallback public DNS (e.g. 8.8.8.8) when the internal gateway DNS times out, or
  2. Inherit DNS settings from the macOS host instead of hardcoding 172.16.10.1, or
  3. Document a supported workaround for corporate VPN environments

Error Messages/Logs

~/Library/Logs/Claude/coworkd.log 
[KERNEL] 2026/04/16 08:23:42 [proxy] MITM proxy started on /var/run/mitm-proxy.sock[KERNEL] 
[KERNEL] 2026/04/16 08:23:42 [rpc] connecting to host CID=2 port=51234
[KERNEL] 2026/04/16 08:23:42 [rpc] connected successfully[KERNEL] 
[KERNEL] 2026/04/16 08:23:42 [coworkd] waiting for IPv4 route[KERNEL] 
[KERNEL] 2026/04/16 08:23:42 [coworkd] IPv4 route not yet available, emitting NOT_CONNECTED[KERNEL] 
[KERNEL] 2026/04/16 08:23:42 [coworkd] configuring static IP on enp0s1: 172.16.10.3/24 gateway=172.16.10.1 dns=172.16.10.1[KERNEL] 
[KERNEL] 
[KERNEL] Ubuntu 22.04.5 LTS claude hvc0
[KERNEL] 
[KERNEL] claude [KERNEL] login:

~/Library/Logs/Claude/main.log
  cycle_health: 'unhealthy',
  had_first_response: true,
  seconds_to_outcome: 255,
  is_resume: false, 
  unhealthy_reason: 'api_error',
  error_message: 'API Error: 587 {"error":"coworkd_upstream_failed","category":"dns_failure","detail":"dial tcp: lookup api.anthropic.com on 172.16.10.1:53: read udp 172.16.10.3:39660->172.16.10.1:53: i/o timeout"}',
  transcript_size_bytes: 2000
}

Steps to Reproduce

Steps to Reproduce

  1. Enable GlobalProtect VPN on macOS
  2. Launch Claude Desktop and start Cowork
  3. Observe coworkd.log: DNS timeout on 172.16.10.1
  4. Observe cowork_vm_swift.log: API reachability UNREACHABLE
  5. Disable GlobalProtect → Cowork starts successfully

Is this a regression?

Yes — Cowork works correctly with GlobalProtect disabled.

Platform

macOS / Anthropic API

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.2773.0 (884b37) 2026-04-15T14:32:09.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Additional Information

This issue affects corporate environments where GlobalProtect is mandatory and cannot be disabled permanently. A DNS fallback or host DNS inheritance option in the VM configuration would resolve this for many enterprise users.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗