Claude Desktop: 'All domains' network egress setting triggers invalid pattern error

Status Fixed / completed

Maintainer reply None cached

Activity 14 comments · opened Jan 29, 2026 · closed Aug 25, 2026

Description

In Claude for Mac Desktop, selecting "All domains" in the network egress/domain allowlist settings causes a validation error on app startup:

Invalid network egress settings
Some hostname patterns aren't valid and will be skipped. Fix or remove them in Settings.

View details
*: Invalid domain pattern. Must be a valid domain (e.g., "example.com") or wildcard (e.g., "*.example.com"). Overly broad patterns like "*.com" or "*" are not allowed for security reasons.

Steps to Reproduce

Open Claude for Mac Desktop
Go to claude.ai → Settings
Set domain allowlist to "All domains"
Restart Claude for Mac Desktop
Open the Cowork tab

Expected Behavior

The "All domains" option should either:

Set a valid internal configuration that doesn't trigger validation errors
Not be offered as an option if * patterns are not allowed

Actual Behavior

The "All domains" option sets a * pattern that the app's own validation rejects, creating a contradictory state where a UI option produces an invalid configuration.

Workaround

Select "Package managers only" or "None" instead of "All domains".

Environment

Claude for Mac Desktop (latest version)
macOS

View original on GitHub ↗

14 Comments

bergatron · 7 months ago

I'm experiencing this on a Team plan where the network egress setting is controlled at the org level by admins. As an individual team member, I have no access to change this setting myself, which leaves me completely blocked from using Cowork until this is fixed.

Impact: Unable to use Cowork at all until either this bug is fixed or our admin changes to a more restrictive network setting.

Dhiwakar1997 · 6 months ago

I couldn't access the internet through claude cowork due to this issue. I need help to fix this issue

robotcan333 · 6 months ago

I have the same problem. CoWork cannot access the internet

anna-filou · 6 months ago

Cowork also can‘t access the internet on my mac (desktop app). This is crazy! Anthropic’s selling a broken feature…

moclippa · 6 months ago

Same issue. It just fails to fetch any domain now.

g-adamante · 6 months ago

also a problem here.

IkerAlus · 5 months ago

same issue here, any solution for Cowork?

linroex · 4 months ago

I am experiencing the same issue again while using the Claude Code schedule feature.

error log:

Network restrictions prevent a direct connection to [hacker-news.firebaseio.com](http://hacker-news.firebaseio.com/). Switched to using WebFetch to retrieve HN data.
Searched the web
Searched the web
I’m sorry, but in this environment, the network proxy has blocked access to the following domains:
• [hacker-news.firebaseio.com](http://hacker-news.firebaseio.com/) (HN API)
• [news.ycombinator.com](http://news.ycombinator.com/) (HN Website)

sagar-jani · 4 months ago

I am facing the same issue even though I have whitelisted all domains for egress in settings.

This is a network/DNS error — the sandbox environment cannot reach the Resend API (api.resend.com). The Resend service responded with a plain-text "Host not identified" (or similar) error instead of JSON, causing the JSON parse to fail on every attempt. No emails were delivered and no dedup state was changed.

Fridrex · 4 months ago

Same here. Can't fetch anything regardless of the egress settings.

jethroborsje · 4 months ago

Same here.

flapflap · 4 months ago

stephent · 3 months ago

When asked what proxy it was referring to, Claude replies:

It's a proxy built into the Cowork/Claude desktop app itself — it's running locally at localhost:3128 and intercepts all outbound network traffic from the bash sandbox to enforce the allowlist. It's Anthropic's mechanism for controlling what the agent can reach, not something on your network or machine.

So the allowlist in Settings → Capabilities is the configuration for that proxy. The fact that it's still blocking after you added the domains and restarted suggests the proxy either isn't reading the updated config, or the setting is stored somewhere it isn't checking.
This is definitely something for Anthropic to fix — the settings UI should be the source of truth for that proxy. Worth reporting as a bug.

It doesn't matter whether I specify domains or choose "All domains", nothing works.

Further testing after explicitly mentioning the domains I need access to in my prompt:

the settings are correctly set to "All domains" for the sandbox. Let me try again right now, and also try web_fetch since you've mentioned both URLs in your message:

then

Still blocked — the proxy is not reading the updated settings at all, even with "All domains" selected. This is a confirmed bug: the UI correctly shows "All domains" but the proxy's blocked-by-allowlist response proves it's ignoring that configuration entirely.

The evidence is pretty clear-cut for a bug report to Anthropic:

Settings → Capabilities → "Allow network egress" → "All domains" is enabled

The sandbox proxy at localhost:3128 still returns X-Proxy-Error: blocked-by-allowlist for every external domain
Restarting Claude Desktop has no effect

hannahmckeand · 3 months ago

Same issue, macOS, All domains setting has no effect