[BUG] [Cowork] VM API unreachable on corporate network — no proxy support in VM environment

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?

Claude Cowork VM starts successfully but cannot reach the Anthropic API when running on a corporate network. The VM boots, connects, installs the SDK — but consistently reports API reachability: UNREACHABLE and Cowork never becomes usable.
No workaround found. The VM is a sealed environment with no exposed proxy configuration.

What Should Happen?

Cowork should provide a mechanism to configure proxy settings (e.g. HTTPS_PROXY, CA certificate injection) so the internal VM can reach the Anthropic API through a corporate proxy.

Error Messages/Logs

[VM] Network status: CONNECTED
[VM:steps] sdk_install completed (5686ms)
[VM:start] Startup complete, total time: 24259ms
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[warn] [VM:network] API is unreachable

This pattern repeats across multiple VM restarts and Claude Desktop versions (2.1.78, 2.1.85, 2.1.87).

Steps to Reproduce

1. Install Claude Desktop with Cowork on a machine connected to a corporate network (Intel internal Wi-Fi in this case)
2. Launch Cowork
3. Observe VM startup completes but API is unreachable

This likely affects all users on corporate networks that route HTTPS traffic through an explicit proxy or firewall. The issue is distinct from the 172.16.0.0/24 subnet conflict reported in other issues — the VM boots and connects successfully, it simply cannot egress to the internet from within the VM.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.87

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This likely affects all users on corporate networks that route HTTPS traffic through an explicit proxy or firewall. The issue is distinct from the 172.16.0.0/24 subnet conflict reported in other issues — the VM boots and connects successfully, it simply cannot egress to the internet from within the VM.