[Feature] Cowork desktop app: support host proxy settings (HTTP/HTTPS/NTLM) for enterprise network environments

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Cowork runs inside an isolated Linux VM within the Claude Desktop application.
This VM has no awareness of the host system's proxy configuration, making Cowork
completely unusable in corporate/enterprise environments that require HTTP or HTTPS
proxies to reach the internet.

Unlike Claude Code CLI (which supports proxy via environment variables like
HTTPS_PROXY, HTTP_PROXY), the Cowork desktop app provides no mechanism to configure
or inherit proxy settings. As a result, all API calls from Cowork fail silently
behind corporate firewalls, and there is no workaround available to end users.

This is a significant blocker for enterprise adoption — particularly in large
organizations (e.g., manufacturing, finance, healthcare) where all outbound traffic
is routed through a corporate proxy, often with NTLM authentication and SSL
inspection.

Proposed Solution

1. Inherit host proxy settings automatically: At Cowork VM startup, read the

host system's proxy configuration (Windows: registry / system proxy settings,
macOS: System Settings > Network > Proxies) and inject them as environment
variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) inside the VM.

1. Manual proxy configuration in Claude Desktop UI: Add a "Network / Proxy"

section in Claude Desktop settings where users can manually specify:

• Proxy URL (e.g., http://proxy.company.com:8080)
• Authentication credentials (username/password or NTLM)
• NO_PROXY exceptions list
• Custom CA certificate path (for SSL inspection environments)

Alternative Solutions

• Some users have attempted to configure CNTLM as a local relay proxy on the host,

but since the Cowork VM does not accept proxy configuration at all, this workaround
does not function.

• Switching to Claude Code CLI is not viable for the non-developer target audience

of Cowork.

• There is currently no known workaround. Users in enterprise environments are

entirely blocked from using Cowork.

Priority

Critical - Blocking my work

Feature Category

Other

Use Case Example

A business analyst at a large corporation wants to use Claude Cowork to automate
file management and reporting tasks on their Windows workstation.

1. They install Claude Desktop and enable Cowork mode.
2. They attempt to use Cowork — but all requests fail because the internal Cowork

VM cannot reach api.anthropic.com.

1. The corporate network requires all outbound traffic to go through an NTLM-

authenticated proxy (e.g., proxy.corp.com:8080).

1. There is no proxy setting in Claude Desktop UI, and the VM ignores the host's

Windows proxy configuration.

1. The user is completely blocked. They cannot use Cowork at all.

If host proxy inheritance were implemented, step 2 would simply work transparently,
with no additional configuration needed from the end user.

Additional Context

• Related issues confirming this is a widespread problem:
• #29367 (OPEN): Cowork Windows — API unreachable behind corporate NTLM proxy
• #30112 (OPEN): Cowork egress allowlist not working with proxy environments
• #30861 (OPEN): Cowork macOS — MITM proxy blocks domains regardless of allowlist
• #35012 (OPEN): Cowork WebFetch blocked by egress proxy
• #34250 (Closed as duplicate of #29367): Regression — was working until Feb 26, 2026

• Claude Code CLI already supports proxy via HTTPS_PROXY / HTTP_PROXY environment

variables. The same capability needs to be surfaced for the Cowork desktop app.

• Priority platforms: Windows (most enterprise deployments), macOS secondary.