Egress proxy blocks api.openalex.org/www.google.com with blocked-by-allowlist / host_not_allowed — reproduces in both Cowork and plain chat

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?

Direct outbound calls to external domains are blocked by the session's egress
proxy, including entirely generic domains (www.google.com), not just a niche
API. Reproduced in two separate surfaces:

1. Cowork task: curl https://api.openalex.org and curl https://www.google.com

both returned no response (HTTP 000, curl exit 56 "connection reset by
peer"), with the proxy reporting X-Proxy-Error: blocked-by-allowlist.

1. Separate plain Claude.ai chat conversation (different session, same

account): the identical two commands both returned 403 — host_not_allowed,
with the message "Host not in allowlist... Add this host to your network
egress settings to allow access."

1. Confirmed the destination itself is healthy: the same

curl https://api.openalex.org run from a normal Terminal session, outside
any Claude sandbox, returns a normal 200 with valid JSON immediately.

This matches the pattern already reported in #93562, #30112, #93507, #93520,
#93525, #92273, #30861, #93494, and #93625 — but I haven't seen the plain-chat
reproduction (point 2) called out explicitly elsewhere in that cluster; it
suggests this isn't Cowork-specific.

What Should Happen?

Either the configured network egress setting should be honored by the
session's proxy as the Settings UI states, or, if these specific domains are
deliberately excluded, the error should say so rather than presenting as the
same generic allowlist miss already reported as a bug elsewhere.

Error Messages/Logs

# Cowork task
$ curl https://api.openalex.org
(no response — HTTP 000, curl exit 56)
$ curl https://www.google.com
(no response — HTTP 000, curl exit 56)
X-Proxy-Error: blocked-by-allowlist

# Plain chat conversation, separate session
$ curl https://api.openalex.org  -> 403 host_not_allowed
$ curl https://www.google.com    -> 403 host_not_allowed
"Host not in allowlist... Add this host to your network egress settings to allow access."

# Normal Terminal, outside any Claude sandbox
$ curl https://api.openalex.org
{"version":"0.1","documentation_url":"/docs","msg":"Don't panic"}

Steps to Reproduce

1. In a Cowork task, run curl https://api.openalex.org and curl https://www.google.com via the code-execution/bash tool.
2. Separately, in a plain (non-Cowork) Claude.ai chat conversation, ask Claude to run the same two commands via its code-execution tool.
3. Compare against running the same curl commands in a normal Terminal session, outside Claude entirely — the destination is reachable there.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude for Mac 2.2553.1 (c38127)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Team/Enterprise-tier organization (org-level plugins and skills are provisioned
for this account). This blocks OpenAlex/CrossRef API calls in an editorial
reference-verification and peer-reviewer-recommendation workflow. Currently
working around it with a local script the editor runs in their own Terminal,
outside the Claude sandbox, since that has normal network access — but this
materially slows the intended workflow compared to the agent making these
calls directly.

Note: this is a Claude Desktop / Cowork sandbox issue, not a Claude Code CLI
issue. Filing here because there is no separate Claude Desktop repository, and
the existing cluster this report cross-references (#93562, #30112, #93507,
#93520, #93525, #92273, #30861, #93494, #93625) — several of which are
themselves explicitly Cowork/Desktop bugs — are filed in this same repo.