[Claude Code on the web] Custom network access for environments

Allow specific domains

To allow domains that aren't in the Trusted list, select Custom in the environment's network access settings, then list one domain per line in the Allowed domains field. This example allows three hosts an internal project might need.

api.example.com
*.internal.example.com
registry.example.com

Sessions in this environment can now reach api.example.com, any subdomain of internal.example.com, and registry.example.com, and no other domains through the session's network. GitHub traffic, MCP connector traffic, and requests to the hosts of the environment's API credentials, other than the hosts that never get the credential, don't go through this allowlist. A leading *. matches every subdomain. To keep the Trusted domains too, check Also include default list of common package managers; leave it unchecked to allow only what you list.

If your organization uses artifacts, you don't need *.frame.claudeusercontent.com in the list for sessions to read them. When the list leaves that host out, Claude Code reads artifact content through the session's connection to Anthropic instead. Keep the host in an allowlist in two situations:

• Sessions in this environment open another organization's public artifacts: Claude Code fetches those from the host directly, so add it to this list.
• You're configuring the local CLI or a self-hosted runner: keep the host in that allowlist. See network access requirements and the self-hosted network requirements.

Each environment has its own allowed-domains list; there's no organization-level allowlist that admins can push to every member's environments. Server-managed settings still apply inside cloud sessions, but none of them adds domains to the environment's network allowlist. To give a team one standard list, an Owner can create an organization-shared environment with Custom network access and that list.