[BUG] Cowork (macOS): all outbound egress lost mid-session from BOTH the desktop workspace and the cloud container; file access unaffected

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

During an active Cowork session on macOS, Claude lost outbound network access from **both** of its
shells at the same moment — the desktop workspace VM on my Mac *and* the cloud container. Only
package registries and Anthropic's own endpoints still resolve. Local file access is completely
unaffected.

This had been working for days, and worked earlier in the same session (Claude cloned a GitHub
repo and queried the HuggingFace API that afternoon).

**This is not the Windows drive-access incident posted on the status page on 10 Sep.** That one is
Windows-only, is about the workspace losing access to the local drive, and states that file
reading and editing still work. Mine is macOS, file access is fine, and the cloud container — which
is not my hardware at all — is affected identically.

## Environment

- Cowork, **macOS** (Apple Silicon), desktop app linked to the computer
- Max plan (personal — no Organization settings available)
- Connected folders working normally throughout

## Expected

Outbound HTTPS from Claude's shells reaches the internet, as it had for days.

## Actual

Measured from the **cloud container**:

| host | result |
|---|---|
| pypi.org | 200 |
| registry.npmjs.org | 200 |
| github.com | 400 (reachable) |
| api.anthropic.com | 404 (reachable) |
| huggingface.co | 000 |
| api.elevenlabs.io | 000 |
| www.google.com | 000 |
| docs.claude.com | 000 |

Measured from the **desktop workspace VM** (`device_bash`): same public hosts fail, and a private
LAN address returns a proxy error:

```
http://192.168.2.75:8189/ -> 403
HTTP/1.1 403 Forbidden
X-Proxy-Error: blocked-by-allowlist
```

The agent proxy's own status endpoint reports:

```json
"recentRelayFailures": [{
"kind": "connect_rejected",
"detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
"host": "api.elevenlabs.io:443"
}]
```

and its `noProxy` list contains `192.168.0.0/16`, so the private address should not have been
proxied at all. (Note curl does not honour CIDR entries in `no_proxy`, only hostnames — so LAN
traffic goes through the proxy in practice.)

## What is unaffected

- Reading, writing and editing local files on the Mac — works perfectly throughout
- Running local commands in the workspace — works
- `WebSearch` / `WebFetch` — work (documented as not subject to egress rules)
- My own terminal on the same Mac reaches every one of these hosts without issue

## Tried, no effect

- Rebooting the Mac
- Starting a brand-new Cowork session (network profile is set at session creation, so this was the
most promising — it failed identically)
- `curl --noproxy '*'` — returns 000; the workspace VM has no independent route

## Impact

Claude can no longer reach any external API or any host on my LAN. In my case that means it cannot
call ElevenLabs or drive a local ComfyUI server, which is the substance of the work. The workaround
is for me to run every network-touching command in my own terminal and let Claude read the results
off disk — functional, but it turns a one-step task into three.

## Timing

Began around **21:30 UTC on 10 Sep 2026**, mid-session.

### What Should Happen?

Claude's shells should have outbound network access, as they did for days before this and
earlier in the same session.

Specifically: HTTPS requests from both the desktop workspace VM and the cloud container should
reach public hosts such as api.elevenlabs.io and huggingface.co, and requests to a private LAN
address should not be refused by the egress proxy — the proxy's own noProxy list contains
192.168.0.0/16, so LAN traffic should bypass it entirely rather than returning
403 blocked-by-allowlist.

Nothing about the session changed to warrant this: same plan, same machine, same folders, no
settings altered. Whatever narrowed the allowlist mid-session should not have applied to a
running session, and should not persist into new ones.

### Error Messages/Logs

```shell
1. Private LAN host, from the desktop workspace VM:

$ curl -s -m 10 -D- -o /dev/null http://192.168.2.75:8189/system_stats
HTTP/1.1 403 Forbidden
Content-Type: text/plain
X-Proxy-Error: blocked-by-allowlist
Date: Thu, 10 Sep 2026 22:24:05 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

Response body: "Connection blocked by network allowlist"

2. Public hosts, from the cloud container (curl exit 28 / no response):

pypi.org 200
registry.npmjs.org 200
github.com 400 (reachable)
api.anthropic.com 404 (reachable)
huggingface.co 000
api.elevenlabs.io 000
www.google.com 000
docs.claude.com 000
support.claude.com 000

3. Agent proxy status endpoint (curl -sS "$HTTPS_PROXY/__agentproxy/status"):

{
"enabled": true,
"port": 36379,
"selective": false,
"standalone": false,
"toolScoped": false,
"noProxy": "localhost,127.0.0.1,::1,...,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,...",
"recentRelayFailures": [
{
"ts": "2026-09-10T22:29:33.957Z",
"kind": "connect_rejected",
"detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
"host": "api.elevenlabs.io:443"
}
]
}

4. Python client, same host (vo.py calling the ElevenLabs API):

urllib.error.URLError:

5. Forcing a direct connection past the proxy from the workspace VM:

$ curl -s --noproxy '*' -m 10 http://192.168.2.75:8189/system_stats
000 (no route)
```

### Steps to Reproduce

I don't have a reliable trigger — it appeared mid-session with no change to settings, plan,
machine or connected folders. These are steps to observe the state, not to cause it.

1. Start Cowork on macOS with the desktop app linked to the computer and a folder connected.

2. In the cloud container, check a few hosts:

for h in pypi.org github.com huggingface.co api.elevenlabs.io www.google.com; do
echo "$h $(curl -s -m 8 -o /dev/null -w '%{http_code}' https://$h/)"
done

Observed: pypi 200, github 400 (reachable), huggingface / elevenlabs / google all 000.

3. In the desktop workspace shell (device_bash), request any host on the local network:

curl -s -D- -o /dev/null http:///

Observed: 403 with X-Proxy-Error: blocked-by-allowlist.

4. Read the proxy's own status:

curl -sS "$HTTPS_PROXY/__agentproxy/status"

Observed: recentRelayFailures contains
"gateway answered 403 to CONNECT (policy denial or upstream failure)".

5. Confirm the machine itself is fine — the same hosts respond normally from a normal terminal
on the same Mac.

6. Confirm file access is unaffected — reading and writing files in the connected folder works
throughout.

Timeline on my machine: worked for several days, including earlier in the same session (a
github clone and HuggingFace API calls both succeeded that afternoon), then stopped at
approximately 21:30 UTC on 10 Sep 2026. A Mac reboot and a brand-new Cowork session both
reproduced the failure identically.

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

Cowork desktop app: 1.49585.0

### Claude Code Version

v2.1.268

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Warp

### Additional Information

_No response_

Start with the desktop workspace's device_bash checks and the cloud-container curl matrix, then inspect the $HTTPS_PROXY/__agentproxy/status output and vo.py's Python request failure. No repository file or test is named, and there is no reliable trigger; done means identifying and verifying a fix that restores expected public and LAN connectivity without affecting file access.

索引モデルが issue の本文から書いたものです。