[Issue Workaround] Cowork Windows: API unreachable if the device is behind proxy - TUN adapter solution

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?

Summary

Sharing a working workaround for Cowork on Windows when behind a corporate HTTP/SOCKS5 proxy. The Cowork Hyper-V VM boots successfully but cannot reach api.anthropic.com because the VM's MITM proxy doesn't properly use the host's proxy configuration. This affects many users on corporate networks.

Environment

• OS: Windows 11 Enterprise 10.0.22631
• Claude Desktop: v1.1.9310 (MSIX)
• Network: Corporate network with mandatory HTTP proxy (Squid), only TCP 80/443 allowed outbound
• Proxy: HTTP proxy at 10.x.x.x:3128 + SOCKS5 proxy on separate machine

Root Cause Analysis

I used Proxifier Windows, and through Proxifier traffic analysis, I identified that Claude Desktop's MITM proxy (which handles VM egress) has two problems behind corporate proxies:

1. QUIC/UDP bypass: claude.exe continuously attempts DNS-over-QUIC connections to [2001:4860:4860::8888]:443 (Google DNS, UDP IPv6). These bypass both the corporate proxy and Proxifier, failing silently.

1. No proxy awareness in MITM proxy: Despite HTTPS_PROXY and HTTP_PROXY environment variables being set at the system level, the MITM proxy component inside claude.exe doesn't properly route VM egress traffic through the corporate proxy. The VM's API reachability check consistently fails:

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

1. Proxifier limitations: Using Proxifier to force claude.exe through SOCKS5 helps for some connections, but the MITM proxy's internal QUIC attempts and local Hyper-V communication create conflicts with Proxifier rule ordering.

Working Solution: Make a network adapter that using proxy, I used TUN Adapter via tun2proxy

The key insight: instead of trying to fix proxy handling at the application/Proxifier level, create a TUN adapter that transparently routes all traffic through a SOCKS5 proxy at the network layer. The Cowork VM's Hyper-V NAT follows the host's routing table, so making the TUN adapter the default route forces VM traffic through the proxy tunnel automatically.

Important Notes

• Corporate network routing: If you need direct access to internal corporate resources (e.g., 10.x.x.x), ensure those subnets have specific routes through your corporate network adapter. tun2proxy --setup only sets the default route; existing specific routes are preserved.
• Proxy dependency: The SOCKS5/HTTP proxy must be reachable before tun2proxy starts. If your proxy is on another machine, ensure network connectivity first.
• --daemonize flag: On Windows, this flag requires Windows Service registration and won't work from CLI. Use Task Scheduler instead.
• Tested with: HTTP proxy (Squid) and SOCKS5 proxy (gost/xray). Both work.
• Proxifier interaction: If using Proxifier or any proxy software, no special rules for Claude are needed with this approach - the TUN adapter handles routing at the network layer.

The Hyper-V NAT operates at the kernel network layer, following the host's routing table. By making the TUN adapter the default route, all VM egress traffic (including the MITM proxy's outbound connections) transparently goes through the proxy tunnel without needing application-level proxy configuration.

Related Issues

• #29367
• #34250
• #24945
• #25024
• #25944
• #26585
• #27785
• #28516
• #41167
• #33946

Feature Request

It would be great if Claude Desktop could natively support proxy configuration for the Cowork VM's MITM proxy, so users behind corporate proxies don't need this workaround. Specifically:

1. Respect system HTTPS_PROXY/HTTP_PROXY environment variables in the MITM proxy component
2. Provide a proxy configuration option in Claude Desktop settings for Cowork
3. Disable QUIC/UDP attempts when behind a proxy (fall back to TCP)
4. If these features cannot be used, maybe add a new network adapter going through proxy like this

What Should Happen?

Cowork on Windows should have work-able network

Error Messages/Logs

Steps to Reproduce

Try to open Claude Cowork that behind any proxied Windows

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.92

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_