anthropics / anthropics/claude-code

Claude Desktop 3p + custom gateway (`ANTHROPIC_BASE_URL`): sandbox network pinned to gateway + api.anthropic.com, `sandbox.network.allowedDomains` ignored even after full app restart

Open
#94,758 0 comments 10 reactions 0 assignees View on GitHub
area:desktop area:networking area:sandbox bug has repro platform:macos
Dominant language
Python
Stars
145k
Forks
23.1k
PR merge metrics
PR metrics pending

Description

## Environment

- Claude Desktop (enterprise 3p deployment, `deploymentMode: "3p"`), macOS (Apple Silicon), app **1.24012.1**
- Embedded Claude Code: **2.1.236** (second machine: 2.1.270), `claude-desktop-3p` entrypoint
- Inference: custom gateway via `ANTHROPIC_BASE_URL=https://gateway..com` (an OpenAI-compatible LLM gateway), auth via `ANTHROPIC_AUTH_TOKEN` (`CLAUDE_CODE_HOST_AUTH_ENV_VAR=ANTHROPIC_AUTH_TOKEN`), `CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST=1`
- Sandbox egress proxy visible in env: `HTTP(S)_PROXY=http://srt:***@localhost:` (54530 / 54743 across sessions)

## What happens

Sandboxed Bash egress is pinned to exactly two hosts. From a sandboxed Bash command:

| host | result |
|---|---|
| `gateway..com` (configured gateway host) | 302 — reachable |
| api.anthropic.com | 404 — reachable |
| api.openai.com | 000, curl exit 56 |
| pypi.org | 000 |
| github.com | 000 |
| internal CI host | 000 |

Blocked hosts fail silently at the srt proxy (no permission prompt appears; on another machine the same blocks surfaced as `deny network-outbound :443 (user denied)` and `curl: (56) CONNECT tunnel failed, response 403`).

## Repro of the settings being ignored

1. Add to `~/.claude/settings.json`:
```json
{ "sandbox": { "network": { "allowedDomains": ["api.openai.com", "pypi.org"] } } }
```
2. Verify file contents. Fully quit the app (tray → Quit) and relaunch.
3. Verify settings still present after restart (they are).
4. Re-run the probes from sandboxed Bash → `api.openai.com` and `pypi.org` still blocked (000/exit 56).

Also checked, no effect / no surface found:
- No egress/network keys exist in `~/Library/Application Support/Claude-3p/claude_desktop_config.json`
- No managed-settings file present (nothing to test on that surface)
- `/sandbox` UI reports everything OK while the proxy keeps denying (second user's report)

Reproduced by 3 users / 3 machines (Claude Code 2.1.236 and 2.1.270), with different target hosts (api.openai.com, pypi.org, github.com, internal CI).

## Expected

`sandbox.network.allowedDomains` (user and/or managed settings) should extend the pinned allowlist — required hosts (gateway, api.anthropic.com) staying implicitly allowed — or the pinned-allowlist behavior of 3p mode should be documented with an admin-deployable override (env var / managed-settings key).

## Impact

Enterprise gateway deployments (the setup Anthropic recommends for orgs) get a sandbox where no dev tooling can reach the network: pip/npm installs, git over HTTPS, internal CI, non-Anthropic APIs. Users work around it by running commands outside the sandbox in their own terminal, and misattribute the failures to the corporate gateway ("it broke after we moved to the corporate gateway").

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the sandboxed Bash probes in Claude Desktop 3p with settings in ~/.claude/settings.json, then inspect the sandbox network behavior and the /sandbox UI. Compare the configured allowedDomains with the hosts actually permitted through the srt proxy. Done means allowed domains take effect in 3p mode, or the pinned allowlist and an admin-deployable override are documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
networking, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.