Claude Code cloud environments set one network access level per environment: None, Trusted, Full, or Custom. Trusted, the default, allows an allowlist of package registries, GitHub, and cloud SDK hosts. Custom takes your own domain list. Some traffic, such as the GitHub proxy and the model API, follows separate rules, so the level is not the whole picture.
The four levels
Anthropic's cloud environments documentation describes each environment as a saved configuration that controls network access, environment variables, and a setup script. Each environment sets one access level for outbound connections.
| Level | What it allows | When it fits |
|---|---|---|
| None | No outbound access through the session's network | Tasks that need only the code already cloned |
| Trusted | Allowlisted domains only: package registries, GitHub, cloud SDKs | Everyday work that installs dependencies |
| Full | Any domain | Rare cases where you accept the exposure |
| Custom | Your own allowlist, optionally including the defaults | Projects with known internal or third party hosts |
The documentation states that a new account's Default environment uses Trusted access, and that each environment has its own allowed domains list. It also says there is no organization level allowlist that admins can push to every member's environments, and no server managed setting adds domains to an environment's allowlist. A team that wants one standard list must create a shared environment and point people at it.
What the level does not control
The same documentation lists traffic that does not follow the level in the way you might assume.
- GitHub operations go through a dedicated proxy that keeps real credentials outside the VM, independent of the access level.
- The model API stays reachable for Claude Code's own requests, even at None. The security section of the cloud sessions page adds that with network access disabled, Claude Code can still communicate with the Anthropic API, which may allow data to exit the VM.
- Hosts listed on the environment's network secrets are reachable even when the level would not otherwise allow them, except for hosts that never receive a secret.
- MCP connector traffic is handled separately.
- All Anthropic hosted traffic passes through a security proxy used for security and abuse prevention.
Read that list as a map of channels, not a flaw. A session has to reach its model and its git host to do anything. Your job is to know which channels exist and decide whether the data they can carry is acceptable.
A worked example: choosing a level for three repositories
An illustrative scenario with three repositories.
Repository A: a public documentation site. Nothing sensitive. Trusted access is fine, because installs need registries. The risk is low, and you would not spend more effort here.
Repository B: a payments service with private packages. Start at None, run a task, and note what breaks. The install fails. Switch to Custom with your private feed and the public registry only. Keep the default hosts off if you do not use them. Add a network secret for the private feed so the token is not an environment variable.
Repository C: an internal tool that calls two partner APIs in tests. Use Custom with the two partner hosts, but ask whether the tests need live partners at all. A mock keeps the destination closed.
The pattern is to begin closed and open on evidence, which matches what the documentation offers: Custom exists so you can list one domain per line instead of widening to Full.
Steps to configure a Custom environment
- Create or edit an environment and pick Custom.
- List one domain per line. The documentation shows examples that allow a host, any subdomain of a domain, and a registry host.
- Decide whether to include the default list. Excluding it narrows access.
- Add network secrets for any credentials, so tokens are attached to requests outside the VM rather than read from variables.
- Run a representative task and read what fails.
- Record the owner and reason for each domain.
Pitfalls
- Treating Trusted as a security control for sensitive code. It is a convenience default. Review the default allowed domains against your threat model.
- Putting tokens in environment variables. The documentation says any command Claude runs can read them, and anyone who uses the environment can read them. Use a network secret where the proxy can attach the key.
- Forgetting the model channel. None does not mean no data can leave.
- Per user environments with no owner. Since there is no organization wide allowlist push, drift is likely unless you standardize on a shared environment.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a guardrail sits between an agent and the tools it can call, which is the same kind of boundary a network level draws for outbound traffic.
Where Safeguard fits
Safeguard does not set Claude Code network levels. Its MCP Guardrail, agent identity, and policies and gates cover what agents and their tools may do, and dependency scanning covers what an allowed registry delivers.
Quick check
Does None mean no data can leave a Claude Code cloud session?
No. The documentation says the model API connection remains, which may allow data to exit the VM. None removes outbound access through the session's network, not every channel.
Can an admin push one allowlist to every member?
Per the documentation, there is no organization level allowlist and no server managed setting adds domains. Owners can create shared environments that members use instead.
Should private package tokens go in environment variables?
Avoid it. Environment values are readable by any command the agent runs. Use a network secret so a proxy attaches the key after the request leaves the VM.
Sources
- Configure cloud environments (Anthropic documentation)
- Use Claude Code in the cloud (Anthropic documentation)
Last reviewed: 19 October 2026.
