Skip to main content
Claude Science connects to a small, fixed set of domains for sign-in, the Claude API, and the app’s own literature search, and to a larger, member-adjustable set of package and research domains when Claude runs analysis code. This page lists them for the team that manages your proxy or firewall allowlist. Connections are outbound-only and almost entirely HTTPS on TCP 443 (an internal package mirror may use 8443). The app’s own domains are fixed, apart from open-access full-text downloads (covered below); the analysis-sandbox domains are a built-in allowlist whose groups members can adjust during onboarding or under Settings > Network. The domains fall into three groups: the app’s own connections every member needs, the analysis sandbox’s package and research domains, and the domains the member’s browser loads. For the proxy and TLS-inspection settings, see Use Claude Science on a corporate network.

​
App connections

Every Claude Science install makes these connections, which travel through the member’s outbound proxy and TLS inspection, so they need the proxy and corporate-certificate settings from the corporate networks page. All are outbound HTTPS on TCP 443. Custom connectors and remote compute that members add reach whatever hosts they are configured with, so allow those case by case. Claude Science’s crash-reporting channel is off and sends no traffic in this release, so it needs no allowlist entry.

​
Full-text and literature retrieval

When Claude searches the scientific literature or retrieves full text, the app itself contacts these hosts over its own connections, which pass through your outbound proxy and TLS inspection like the app connections above, so the proxy must allow them even though several are also on the sandbox allowlist. Full-text downloads come from wherever the open-access copy of an article is hosted, so on a network that allows only listed hosts, expect retrieval of some full-text copies to fail; the domains below keep literature search and PubMed retrieval working.

​
Analysis sandbox domains

When Claude runs code, its network access passes through a local filtering proxy that allows only the domains on the sandbox’s built-in allowlist, grouped by purpose below. These are member-level controls with no organization-level setting: members can turn off any group except package management, during onboarding or under Settings > Network, and add allowed domains of their own in Settings. An administrator can instead use the per-device configuration file, whose [sandbox.network] keys add allowed or denied domains, or disable sandbox networking entirely.

​
Package management domains

These domains are always on the sandbox allowlist and supply Python, R, and system packages when Claude builds an analysis environment. Claude Science itself does not require GitHub; the package manager ships inside the app. The GitHub domains are used only when a package Claude installs is published as a GitHub release or a member imports a skill from a GitHub repository, and blocking them fails only those operations. When you configure a conda channel mirror, Claude Science removes only the conda hosts (conda.anaconda.org, repo.anaconda.com, anaconda.org, *.anaconda.org) from the allowlist, and a Python index mirror removes only pypi.org, *.pypi.org, and files.pythonhosted.org. The *.conda.io, CRAN and Bioconductor, npm, and GitHub rows stay. A removed host is reachable again if a member re-adds it under Settings > Network or an administrator lists it in [sandbox.network] allowed_domains, which takes precedence over the removal. Environment builds contact the mirror host directly from the workstation, not through the outbound proxy, so it must be reachable directly (over your VPN or internal network if the mirror is internal, HTTPS on TCP 443 or 8443). A proxy allowlist entry alone does not make the mirror reachable for builds, and build-time mirror traffic will not appear in your proxy logs. See Point package installs at an internal mirror.

​
Research database domains

These groups are on by default and can be turned off during onboarding or anytime under Settings > Network.

​
Optional compute integrations

These domains matter only when a member turns on the matching integration.

​
Domains the sandbox always blocks

The sandbox blocks a built-in list of common destinations for moving data out of an organization (anonymous file-upload and paste services, chat and webhook endpoints that accept posted data without an account, reverse-tunnel services, and path-style cloud object storage addresses), and neither members nor configuration can remove entries from it. The blocklist is enforced only inside the analysis sandbox, so it does not affect the app’s own connections, such as the update check to storage.googleapis.com listed under App connections above. For the path-style object-storage entries (s3.amazonaws.com, s3.<region>.amazonaws.com, storage.googleapis.com, commondatastorage.googleapis.com, and r2.cloudflarestorage.com), a bucket named in the URL path is blocked, while a bucket named in the hostname (for example <bucket>.s3.us-west-2.amazonaws.com or <bucket>.storage.googleapis.com) can be added to the allowlist under Settings > Network. If your package mirror or a cloud workflow stores data in object storage, address the bucket by hostname.

​
Domains the member’s browser loads

Sign-in pages and interactive previews load in the member’s web browser, so they are governed by your web-filtering policy rather than the outbound proxy or the sandbox allowlist. If your policy blocks these domains, sign-in pages fail to load or interactive previews render blank or broken.