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

[leesk212]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• 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.

2. 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.
3. The corporate network requires all outbound traffic to go through an NTLM-
   authenticated proxy (e.g., proxy.corp.com:8080).
4. There is no proxy setting in Claude Desktop UI, and the VM ignores the host's
   Windows proxy configuration.
5. 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:

  • [BUG] Cowork Windows: API unreachable from VM behind corporate NTLM proxy (cntlm) #29367 (OPEN): Cowork Windows — API unreachable behind corporate NTLM proxy
  • [BUG]Cowork network egress allowlist not working - custom domains blocked with 403 blocked-by-allowlist #30112 (OPEN): Cowork egress allowlist not working with proxy environments
  • [BUG] Cowork macOS: MITM egress proxy blocks all non-API domains regardless of allowlist settings #30861 (OPEN): Cowork macOS — MITM proxy blocks domains regardless of allowlist
  • [BUG] Cowork mode: WebFetch egress proxy blocks most websites (Facebook, Netlify, etc.) AND Chrome extension fails to connect — no fallback path to view any web content #35012 (OPEN): Cowork WebFetch blocked by egress proxy
  • [BUG] Cowork Windows: API unreachable behind corporate proxy — regression from working state (was working until Feb 26, 2026) #34250 (Closed as duplicate of [BUG] Cowork Windows: API unreachable from VM behind corporate NTLM proxy (cntlm) #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.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Cowork Windows: API unreachable from VM behind corporate NTLM proxy (cntlm) #29367
2. [BUG] [Cowork] VM API unreachable on corporate network — no proxy support in VM environment #41167
3. [Issue Workaround] Cowork Windows: API unreachable if the device is behind proxy - TUN adapter solution #44244

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[future-rtakahashi]

The same issue exists in Claude Desktop as well.

As a result, our organization is currently unable to provide either Claude Desktop or Cowork, which is extremely inconvenient.
We request that this issue be addressed as soon as possible.

[jmmfcoutinho]

Are there any update on this topic?
This is a very big detractor for enterprise adoption!

[king-sheol]

I published a related unofficial Windows Desktop workaround that may help one adjacent case, but I want to be careful about scope:

https://github.com/king-sheol/claude-desktop-windows-proxy-launcher

Latest release ZIP:
https://github.com/king-sheol/claude-desktop-windows-proxy-launcher/releases/latest

This is not a full fix for Cowork VM egress, NTLM proxy support, or enterprise VM networking. Those still need proper upstream support from Claude Desktop / Cowork.

The workaround is only for cases where the host browser can reach claude.ai, but the main Claude Desktop Electron UI cannot connect through the same local/corporate proxy path. It launches the existing Claude.exe with explicit Chromium proxy flags and proxy env vars, without modifying Anthropic app files or deleting user data.

Why I am linking it here:

• The issue asks for host proxy support in Claude Desktop / Cowork.
• Some users appear to have two related but separate failures: the main Desktop UI proxy path, and Cowork VM proxy egress.
• This launcher may help the first failure mode while leaving the VM/Cowork egress problem for Anthropic to solve properly.

For enterprise environments, the real fix should still be first-class proxy settings in Claude Desktop, including host proxy inheritance, manual proxy configuration, NTLM/local relay support, NO_PROXY handling, and custom CA support where needed.

[mjramer]

I added proxies to my managed settings env block to resolve this (I'm on a Bedrock 3P deployment):

{
  "env": {
    "HTTP_PROXY": "http://my-proxy.com",
    "HTTPS_PROXY": "http://my-proxy.com",
    "http_proxy": "http://my-proxy.com",
    "https_proxy": "http://my-proxy.com",
    "NO_PROXY": "localhost,127.0.0.1,"
}