Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.309 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeDocsClaude Documentation
One capture · claude-docs

One read of Claude Documentationclaude-docs-20261022T193711Z

1 pages moved out of 279 read.

Pages moved 1 significant first
Pages read 279 in this capture
Captured 19:37 UTC
Corpus hash cc3c4470648f corpus-hash

What this read moved

1-1 of 1

third-party/claude-desktop/network-proxy Changed · +4 / -2 lines

from line 67
6767Three behaviors to plan for:
6868 
6969* If the pinned proxy is unreachable, requests fail. The app does not fall back to a direct connection.
70* If a pinned PAC script cannot be downloaded, the app connects directly and the agent gets no proxy. Cowork's sandboxed shell gets its own copy of the script through a separate download when the sandbox starts. If that download fails, the shell connects directly too, and the download isn't tried again until the sandbox next starts. Combine the key with network-layer egress rules if a silent fallback to direct is not acceptable (see the warning below).
70* If a pinned PAC script cannot be downloaded, the app connects directly and the agent gets no proxy. Cowork's sandboxed shell gets its own copy of the script through a separate download when the sandbox starts. If that download fails or returns something other than a PAC script, such as a sign-in page, the shell connects directly. The download isn't tried again until the sandbox next starts, so quit and reopen Claude Desktop on the affected device once the script is reachable. Combine the key with network-layer egress rules if a silent fallback to direct is not acceptable (see the warning below).
7171* Inside Cowork's sandboxed shell, a pinned PAC script's `myIpAddress()` returns the sandbox's internal address rather than the device's, so a script that chooses a proxy by client subnet can give the shell a different answer than it gives the device.
7272 
7373## What is and is not routed
from line 97
9797Some traffic never uses the pinned key or the proxy the app resolved, and it is worth being explicit about each case and what you can do about it.
9898 
9999* **App updates.** Checking for and downloading Claude Desktop updates is handled by the OS-native updater on macOS and Windows, which follows the OS proxy settings only. This is the one app-controlled path with no admin-side option other than the OS proxy: neither the pinned key nor Claude Code managed settings reach it. If updates must not traverse a direct path, configure the OS proxy on the device or distribute updates yourself with [`disableAutoUpdates`](/docs/third-party/claude-desktop/configuration) and your software-distribution tool. On Linux, updates come from your package manager, which has its own proxy configuration.
100* **Commands in Cowork's sandboxed shell on Linux.** No proxy settings reach the Cowork sandbox on Linux, so `curl`, `pip`, `npm`, `git`, and anything else the agent runs there connect directly. On macOS and Windows those commands follow the pinned key, or the OS proxy settings when no key is set, and are not a bypass. On every platform, [`coworkEgressAllowedHosts`](/docs/third-party/claude-desktop/web-tools) still applies inside the sandbox and sits in front of any proxy, so an allowed host is then reached through the proxy.
100* **Commands in Cowork's sandboxed shell.** No proxy settings reach the Cowork sandbox on Linux, so `curl`, `pip`, `npm`, `git`, and anything else the agent runs there connect directly. On macOS and Windows those commands follow the pinned key, or the OS proxy settings when no key is set. When the key or the OS settings name a PAC script, the commands follow it only while the sandbox has [its copy of the script](#pac-script-for-the-sandboxed-shell). If the download of a pinned PAC script fails when the sandbox starts, the commands connect directly until the sandbox next starts. On every platform, [`coworkEgressAllowedHosts`](/docs/third-party/claude-desktop/web-tools) still applies inside the sandbox and sits in front of any proxy.
101* **SOCKS proxies in Cowork's sandboxed shell.** On macOS and Windows, the sandboxed shell skips SOCKS proxies. Its commands connect directly to a host for which a PAC script returns only SOCKS proxies, and to every host when the OS proxy settings name only a SOCKS proxy. Have the script return a `PROXY` or `HTTPS` entry for each host that must go through a proxy, or [pin a proxy from managed configuration](#pin-a-proxy-from-managed-configuration).
102* **Cowork's sandboxed shell when every host is allowed.** With a list of hosts in [`coworkEgressAllowedHosts`](/docs/third-party/claude-desktop/web-tools), the shell's commands reach the network only through a filter inside the sandbox, and a program that ignores proxy variables has no route around it. When the list contains `*`, that filter is off and commands make their own connections. On macOS and Windows they get the proxy setting only as `HTTPS_PROXY`, `HTTP_PROXY`, and `NO_PROXY`, so a program that ignores those variables connects directly.
101103* **SSH remote Code sessions.** When a user runs a Code session on another machine through [`sshHostAllowlist`](/docs/third-party/claude-desktop/ssh-remote-sessions), the agent runs on that host and connects to the inference endpoint from there. Claude Desktop passes the endpoint address to the remote agent but not the pinned key, the device's OS proxy settings, or proxy variables from Claude Code managed settings on the device. The host's own network route and any Claude Code managed settings installed on the host apply instead. See [Inference credentials on the remote host](/docs/third-party/claude-desktop/ssh-remote-sessions.md#inference-credentials-on-the-remote-host).
102104* **Pages opened in the system browser.** Some sign-in flows open your default browser. That traffic follows the browser's proxy settings, which normally track the OS; pin it with the browser's own policy (for example, the Chrome or Edge `ProxySettings` policy) or the device's network profile.
103105* **Brokered Microsoft Entra sign-in.** When [brokered authentication](/docs/third-party/claude-desktop/entra-broker.md) is in use, the token request is made by Company Portal (macOS) or Web Account Manager (Windows), not by the app. Those components follow the OS proxy settings; configure them through the same MDM that manages the device.
Feedback