One read of Claude Documentationclaude-docs-20260814T092040Z
213 pages moved out of 213 read.
Pages moved
213
significant first
Pages read
213
in this capture
Captured
09:20 UTC
Corpus hash
dfa3e64bc187
full baseline · baseline
What this read moved
1-25 of 213, page 1 of 9This capture is too large to show at once. Changes 1-25 of 213 are below, significant first; the rest are on the following screens.
claude-science/admin-controls First recorded · 80 lines, first recorded
# Admin controls ## Identity and access ## Capability toggles ## Connectors ## Data and privacy ## Audit and compliance ## Usage, models, and billing ## Offboarding and local data
The first capture of this source. The page was already there, and this is what it said.
# Admin controls > Members sign in to Claude Science with their Claude account, so your identity and billing controls apply automatically. Members sign in to Claude Science with their Claude account, so your identity and billing controls apply automatically. Because the app stores conversations on each member's computer rather than on Anthropic's servers, most of the data-handling controls Anthropic provides don't reach that data today. The tables show, for each admin setting, whether it governs Claude Science in beta. Status values describe Claude Science specifically; other Claude products may differ. Legend: Supported / Partial / Not available / Not applicable ## Identity and access | Admin setting | Status in Claude Science beta | Note | | --------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SSO (SAML / OIDC) | Supported | Sign-in goes through claude.ai, so your SSO policy applies automatically. | | SCIM / Directory Sync | Supported | Deprovisioning a member revokes their access. | | Domain capture | Supported | Inherited from claude.ai account creation. | | Members management | Supported | Adding or removing org members controls who can sign in. | | Built-in roles | Supported | All built-in roles get access once the product is enabled for the org. | | Custom roles | Supported | Custom roles can grant or deny access to the app. | | Groups | Supported | Roles assigned through groups carry through. | | IP allowlisting | Partial | Claude inference is IP-gated. Gating remote compute (running code on the member's own SSH hosts or cloud accounts) is on the roadmap. Custom connectors and local operation are outside this setting's scope. | | Session duration | Partial | Limits the browser sign-in step only; the app stays signed in after that. | ## Capability toggles | Admin setting | Status in Claude Science beta | Note | | -------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Org enable toggle | Supported | Off by default for Team and Enterprise; an Owner or Primary Owner turns it on under Organization settings > Claude Science. Assigning seats doesn't turn it on. | | Completion feedback (thumbs) | Supported | The org toggle hides the feedback buttons, same as Chat. | | Organization custom instructions | Supported | The org's custom instructions are applied to the app's model calls, the same as Chat. | | Skills allowlist | Partial | Org-published skills appear, but members can also install local skills without restriction. Adding admin control is on the roadmap. | | Web search | Not available | The app offers web search regardless of this setting. Adding admin control is on the roadmap. | | Code execution | Not available | This setting controls Chat's hosted code sandbox only. Claude Science runs code locally regardless of this setting; that's core to the product. | | Code execution network allowlist | Not available | This setting controls Chat's hosted code sandbox only and is not yet available for Claude Science in Organization settings. Claude Science's local sandbox keeps its own allowlist, which members manage in the app and administrators can extend per device with the sandbox network keys in the [configuration file reference](/docs/claude-science/configuration-file-reference). | | Location metadata | Not applicable | The app doesn't derive, store, or send any geolocation data. | | Memory | Not applicable | The claude.ai Memory setting doesn't control memory in Claude Science. The app keeps its own memory locally on the member's device, and it's off by default. | | Projects | Not applicable | No Projects integration; the app uses local workspaces instead. | ## Connectors | Admin setting | Status in Claude Science beta | Note | | ---------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Org-published Directory connectors | Supported | Connectors the admin publishes are available in the app. | | Per-role connector restrictions | Partial | Enforced for Directory connectors, not for connectors members add locally. | | Org plugin allowlist | Partial | Org-published plugins appear automatically; members can still add their own local skills and connectors. Adding admin control to restrict local skills and connectors is on the roadmap. | | Connector tunnels | Partial | Directory connectors the admin publishes reach the app through tunnels. Local connectors the member adds run on their own computer, so tunnels don't apply. Custom remote connectors the member adds don't route through tunnels. | | Custom connector restrictions | Not available | Members can add their own custom connectors regardless of the organization allowlist. Adding admin control is on the roadmap. | | Desktop Extension allowlist | Not applicable | Desktop Extension directory isn't available in the app. | ## Data and privacy | Admin setting | Status in Claude Science beta | Note | | ------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CMEK | Supported | Applies to the product's model traffic the same as Chat. | | Data processing geography | Partial | Covers Anthropic-hosted processing, not remote compute you configure (code the member runs on their own SSH hosts or cloud accounts) or the member's computer (same as Claude Code). | | HIPAA | Partial | HIPAA-ready organizations can enable the Claude Science beta, but usage isn't covered under the BAA. | | Custom Data Retention | Not available | The auto-delete window doesn't cover local data or the usage logs Anthropic keeps for this product. | ## Audit and compliance | Admin setting | Status in Claude Science beta | Note | | --------------- | ----------------------------- | ----------------------------------------------------------------------------------- | | Audit log | Not available | No events recorded yet; on the roadmap. | | Compliance API | Not available | Admins can't export or delete this product's data through the API. | | Org data export | Not available | The export doesn't include data stored on members' computers (same as Claude Code). | ## Usage, models, and billing | Admin setting | Status in Claude Science beta | Note | | --------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Usage limits | Supported | Usage counts toward the same 5-hour and weekly limits as Claude Code and Cowork. | | Billing and seats | Supported | Uses the same seat as the rest of claude.ai. | | Model access controls | Supported | Uses the standard model API, so the org's allowed-model list and model access grants apply to both the model picker and the calls themselves. | | Usage analytics | Supported | Open Analytics from the user menu; the Claude Science tab shows usage, and spend is filterable by product on the Overview tab. | ## Offboarding and local data | Admin setting | Status in Claude Science beta | Note | | ------------------------ | ----------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Offboarding (local data) | Not available | Removing a member doesn't wipe data already on their computer. | | Local deletion signal | Not available | Deleting local data doesn't notify Anthropic to drop the matching server-side record early. This is on the roadmap. |
claude-science/annotations First recorded · 19 lines, first recorded
# Annotations ## Leaving an annotation ## Sending annotations to Claude
The first capture of this source. The page was already there, and this is what it said.
# Annotations > Annotations let you attach comments to specific parts of an artifact instead of describing a location in prose. Annotations let you attach comments to specific parts of an artifact instead of describing a location in prose. Select text in a Markdown, plain-text, LaTeX, or code file; select text in a PDF (one page at a time); click a point on an image or figure; or turn on **Annotate** and click an element in a rendered HTML report. Tables and other artifact types can't be annotated. Session transcripts can also be annotated. ## Leaving an annotation * Select content and click the **Annotate** pill. * Type your comment and press Cmd/Ctrl+Enter (or click **Save**). * The annotation appears as a highlighted badge (text) or numbered pin (images). Hover to read it; click to **Edit** or **Delete**. ## Sending annotations to Claude Saving an annotation doesn't send it. Pending annotations collect in an **N comments** chip on the composer and are sent with your next message. This lets you batch several annotations and send them together, or send them one at a time. Claude receives each annotation with its filename, the quoted selection (or marked image), and your note. Once sent, annotations are consumed: they leave the artifact and appear as cards on the message. Annotations don't have threads or a resolve state. To revise an artifact again after Claude updates it, annotate the new version. Limits: annotation text is capped at 1,000 characters. PDF selections can't cross page breaks. Annotations aren't included in downloads and don't appear in the **Files** grid.
claude-science/artifacts First recorded · 35 lines, first recorded
# Artifacts ## Working with artifacts ## Versions ## Provenance ## Deleting artifacts
The first capture of this source. The page was already there, and this is what it said.
# Artifacts > An artifact is a file Claude saves into the project: a figure, processed dataset, report, notebook, or other output. An artifact is a file Claude saves into the project: a figure, processed dataset, report, notebook, or other output. Artifacts are stored on your computer in the app's data folder and persist until you delete them. Other files Claude writes during a session are temporary and are cleared a few hours after the session ends; ask Claude to save a scratch file if you want to keep it. ## Working with artifacts Click a linked file in the conversation to open it in a tab beside the chat. HTML artifacts have zoom controls, including fit to width; images zoom up to their native resolution. Open **Files** in the sidebar for a searchable grid of every artifact in the project. From an artifact's menu you can: Open, Open beside session, **View in context**, **Provenance**, Versions, **Copy link**, **Star**, **Rename**, **Download**, or **Delete**. Renaming doesn't break links. **Delete** removes all versions permanently. Files you attach or drop into the composer are listed under **Your uploads**. To copy artifacts outside the app, use **Download** for a single file, or open the project's folder under \~/.claude-science and copy the files directly. ## Versions When Claude saves the same filename again in the same session, the artifact gains a new version. You can also edit text-based artifacts (Markdown, code, plain text) directly: click **Edit content**, make changes, and **Save** to create a new version. Images, PDFs, HTML, and tables can't be edited in place. When an artifact file is open, a version stepper and a diff toggle appear. In diff mode, you can choose which earlier version to compare against; the previous version is the default. Older versions are read-only; to restore one, ask Claude to save it again. Links Claude puts in the conversation point to the specific version that existed at the time. ## Provenance Every artifact version records how it was made. Open **Provenance** from an artifact's menu to see five tabs: * **Messages**: the conversation around the save. * **Code**: a reproducible script, downloadable as a script or notebook. * **Execution Log**: every command that ran. * **Environment**: the environment name, language version, and every installed package with its version. * **Review**: findings from [the reviewer](/docs/claude-science/the-reviewer). The **Execution Log** is the authoritative record of what ran. If the **Code** tab and the log disagree, trust the log. ## Deleting artifacts Deleting a session keeps its artifacts and their provenance. Deleting a project deletes all of its sessions, artifacts, and project-scoped memory.
claude-science/changelog First recorded · 92 lines, first recorded
# Claude Science changelog
The first capture of this source. The page was already there, and this is what it said.
# Claude Science changelog > Release notes for Claude Science, including new features, improvements, and bug fixes by version. <Update label="0.1.27" description="August 7, 2026"> * On macOS, installs that showed an environment setup error in their first session now repair themselves automatically after updating; the Featured connectors become available once the repair finishes, which can take a few minutes * Star a session from its menu to keep it in a Starred section at the top of your project's session list * Get notified when any of your sessions finishes or needs your input, even while you work in another project. In-app notifications are on by default; sound and desktop notifications are under Settings > General > Notifications * Set reasoning effort for a single session from the session options next to the message box; the value in Settings stays the default for new sessions * On Pro and Max plans, see your credit balance and monthly spend limit and turn usage credits on or off under Settings > Usage * When you ask for a plan, Claude now waits for your approval before running code or marking steps done * Lots of other miscellaneous improvements and fixes </Update> <Update label="0.1.21" description="July 21, 2026"> **New** * **Improved context preservation.** On Max, Team, and Enterprise plans, sessions go much further before older messages are summarized. * **Works on corporate networks.** Sign in and install packages on networks with corporate proxies, TLS inspection, or authenticated package mirrors. Mirror credentials go in Settings. No config files needed. * **Search your memories.** Find anything Claude remembers from the memory screen. Results are highlighted and jump to where they live. The screen also loads faster now. * **Archive projects.** Tidy your project list without deleting anything; archived projects keep all their data and can be brought back anytime. * **Password sign-in for SSH machines.** Adding a remote machine that asks for a password instead of a key is now supported. You're prompted when it's needed, and the password is never saved to disk. * **Compute monitor.** See every running kernel with its memory and CPU use from the new Compute tab. Kernels can be stopped if needed with optional feedback sent to the agent such as "redo this analysis using less memory". **Improvements and fixes** * **Richer artifact previews.** HTML files show rendered thumbnails, Word documents show text previews, large CSVs show their structure, and PDFs show their first page. * **Parquet files open as tables.** See a parquet file's columns and first rows right in the app, even for very large files. * **Memories stay in their project.** Notes from one project no longer surface in another. * **Annotations travel with your message.** Annotations you've added appear above the message box and carry over when you open a side chat. * **Less disk space for huge files.** When Claude saves the same very large file over and over, it can now keep just the latest version instead of every copy. * **The conversation view holds still.** Images no longer shove the page as they load, "View in context" lands on the right message, and mentioning a file always attaches the right one. * **Edit messages with attachments.** Editing an earlier message now supports file mentions, attachments, and uploads. * **Many other miscellaneous fixes and improvements.** </Update> <Update label="0.1.18" description="July 9, 2026"> **Features** * Sessions now pause and ask for your confirmation before spending extra usage. Billed usage credits are never drawn on a dismissible warning alone. * Claude can now monitor how much memory and processing power its computations are using, and plan its work accordingly. * Search from inside a project: the project view now has a search button that opens the same search as Cmd+K. * Download any artifact from any surface: every artifact menu now includes a download option. * Starred artifacts now pin to a new Starred section at the top of the Library, with a star badge. **Fixes** * Fixed a crash that could prevent very large sessions from loading. * Fixed several ways a running session could stall or stop early, including long thinking pauses being cut off mid-run and sessions resuming incorrectly after a crash. * Fixed the app sometimes becoming unresponsive after an automatic update. * Code blocks now switch correctly when your system switches between light and dark mode. * Lots of other miscellaneous improvements and fixes. </Update> <Update label="0.1.17" description="July 8, 2026"> * **Fixed a bug where idle sessions were consuming usage.** * Lots of other miscellaneous improvements and fixes. </Update> <Update label="0.1.16" description="July 7, 2026"> **Features** * Auto-review is now available on the Pro plan: turn it on from the session settings, and it stays off until you do. * Artifact previews: zoom HTML artifacts (including fit to width), zoom images to native resolution, and choose which version an artifact diff compares against * Import skills from private GitHub repositories using your own GitHub credentials * LaTeX previews now resolve cross-references — \ref, \eqref, and section numbering render the way your document intended * Dashboard upgrades: a project switcher with live per-project status, project names on the "Now" cards, a visible search button, and ⌘K search now matches project descriptions too * Annotate artifacts faster: drag image annotation pins to reposition them, and use @/# mentions in annotation comments **Fixes** * Pasted attachments no longer disappear before their first use, very large text and JSON previews no longer freeze the tab, and a stale usage-limit banner now clears itself once your usage limit resets * Cloning a repo or unpacking an archive no longer floods the chat with every image it contains * The Reviewer no longer gets stuck on "Reviewing…" or hides its findings tray * Flaky read-only connector tool calls now retry once automatically instead of failing your turn, and connector setup errors tell you what's actually wrong * A corrupt pasted image no longer breaks the transcript * Upgrading with a very large history database no longer fails partway through * Fixed a crash when the browser's auto-translate feature modified the page * Lots of other miscellaneous improvements and fixes </Update> <Update label="0.1.15" description="July 1, 2026"> * Corporate networks: environment builds now work behind TLS-inspecting proxies (such as Zscaler or Netskope). On macOS, corporate root CAs in your keychain are picked up automatically for conda/pip package downloads; on macOS or Linux you can also point at a CA-bundle file under Settings > Network > Package mirror. The mirror card's Check button now verifies TLS trust with the same bundle the builds use. (In-session `pip`/`curl` and the Desktop app's guest-VM builds are not covered) * Package mirrors: point conda and pip at your organization's internal mirror (Artifactory/Nexus) via Settings > Network > Package mirror. Setting a mirror also drops the public package hosts from the sandbox network allowlist * OpenAlex now requires a free API key for full-text access. Claude Science resolves access automatically or asks you in the session when a key is needed; you can also add and validate a key anytime under Settings > Credentials * New Context usage view: see how full a session's context window is and where tokens go, from the + menu in the composer * Lots of other miscellaneous improvements and fixes </Update> <Update label="0.1.14" description="June 30, 2026"> * Public launch of Claude Science </Update>
claude-science/cloud-storage First recorded · 19 lines, first recorded
# Cloud storage
The first capture of this source. The page was already there, and this is what it said.
# Cloud storage > Connect Amazon S3, Google Cloud Storage, or Azure Blob Storage so Claude can read data and write results in place, with your permission. Connect Amazon S3, Google Cloud Storage, or Azure Blob Storage so Claude can read data and write results in place, with your permission. In **Settings > Credentials**, choose **AWS**, **Google Cloud**, or **Microsoft Azure**, then Connect. Provide the credential (access key, service-account JSON, HMAC key, service principal, or connection string) and list the bucket names (AWS, GCP) or **Blob containers** (Azure) this credential covers. S3-compatible stores use the AWS form with the **S3-compatible endpoint** field; you'll need to allowlist that endpoint host separately. Listing a bucket adds its address to the sandbox network allowlist so code can reach it without a per-call card. Access within the bucket is still limited to the credential's permissions. Credentials are encrypted on your computer and sent only to the provider they belong to. Claude reads and writes objects with ordinary code using the provider's Python library (`boto3`, Azure SDK). **Settings > Storage** lists connected credentials and lets you browse and import objects (up to 100 GB) or export artifacts. <Note> From code, reach Google Cloud Storage with an **HMAC key** via `boto3`, or use the import/export flow. `gsutil`, `gcloud storage`, and the google-cloud-storage Python library use path-style addresses that aren't reachable from the sandbox. </Note> <Warning> Any code Claude writes can use credentials you add here. If a bucket should never be reachable from an analysis session, don't add its credential. </Warning>
claude-science/command-line-settings First recorded · 71 lines, first recorded
# Command line settings ## Commands ## Global flags ## The login link ## Flags for serve ## Dangerous flags ## Environment variables ## See also
The first capture of this source. The page was already there, and this is what it said.
# Command line settings
> Reference for the claude-science command: every subcommand, the serve flags, the single-use login link, and the environment variables Claude Science reads.
Reference for the claude-science command: every subcommand, the serve flags, the single-use login link, and the environment variables Claude Science reads.\
claude-science serve starts Claude Science and opens the web app in your browser at a single-use login link. Everyday use is that one command. The others manage the running program: they mint login links, report status, follow logs, install updates, and merge data directories.
## Commands
| Command | What it does |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `claude-science serve` | Start the background program and open the web app in your browser at a single-use login link. One runs per data directory; Ctrl-C stops it. |
| `claude-science open` | Mint a fresh login link from the running program and open it in your browser. |
| `claude-science url` | Print a fresh login link alone on standard output and nothing else. |
| `claude-science status` | Print whether the program is running, the version, and the port, as JSON. |
| `claude-science logs` | Print the newest log file from the data directory. `--tail` follows it live. |
| `claude-science stop` | Stop the program cleanly. |
| `claude-science update` | Check for and install an update. `--check` only reports; --to `<version>` installs a specific version, which is also how you roll back. Updates are signature-verified and replace the binary atomically. |
| `claude-science import` `<path>` | Merge another data directory, or its database file, into this one. |
| `claude-science --version` | Print the version. |
| `claude-science` `<command>` --help | Print help for any command. |
<Note>
`import` has no preview and no undo. Back up the data directory before you run it; running the same import a second time is safe.
</Note>
## Global flags
These two work on every command.
| Flag | Default | What it does |
| -------------------- | ------------------------------- | ------------------------------- |
| `--data-dir` `<dir>` | `~/.claude-science` | The data directory to use. |
| `--config` `<file>` | `~/.claude-science/config.toml` | The configuration file to read. |
## The login link
When serve starts, it prints a line of the form `Web UI -> http://localhost:<port>/?nonce=...`. The nonce is a one-time password: it signs one browser tab in and then expires, about three minutes after it is printed. The signed-in tab stays signed in until you restart the program.\
You never need to keep a link. claude-science open mints a fresh one and opens it in your browser whenever you want to sign in again. For a machine you reach over SSH, claude-science url prints a fresh link alone on standard output: run it there, then open the printed link through your tunnel. The app listens on 127.0.0.1 unless you change --host, so it is reachable only from your own machine.
## Flags for serve
| Flag | Default | What it does |
| ------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `--port` `<n>` | `8000` | The port the web app is served on. 0 picks a free port. |
| `--no-browser` | off | Do not open a browser. url prints a login link any time you want one. |
| `--detached` | off | Run in the background. Implies --no-browser. |
| `--no-auto-update` | off | Do not check for or install updates. For a pinned or centrally managed install. |
| `--host` `<address>` | 127.0.0.1 | The address the app listens on. Anything else exposes the app to your network; prefer an SSH tunnel. |
| `--base-path` `</prefix>` | unset | Serve the app under a URL prefix behind a reverse proxy. |
| `--allow-origin` `<url>` | unset | An extra browser Origin allowed to connect; repeat the flag for more than one. It does not change which sites Claude can reach. |
| `--sandbox-port` `<n>` | port + 1 | The separate origin that previews of generated HTML are served from, so a previewed page cannot read your session. |
| `--verbose` | off | Show startup and info log lines on the console; by default they go only to the log file. |
## Dangerous flags
<Warning>
`--dangerously-no-sandbox` runs code with full read and write access to your home directory and an unrestricted network. `--dangerously-skip-approvals` approves every permission card automatically, for everything, until you restart without the flag; questions addressed to you still appear. Neither belongs in everyday use.
</Warning>
## Environment variables
`DO_NOT_TRACK`, set to any value, turns usage analytics off. It is the same switch as `disable_telemetry = true` in the configuration file. `GITHUB_TOKEN` is optional and is used only against `api.github.com`, to lift the rate limit when you install a skill from a GitHub repository. Claude Science also reads the standard proxy variables (`HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY`, and `ALL_PROXY`); see [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks#connect-through-an-outbound-proxy). The proxy address variables are the one case where the environment overrides the configuration file, and `NO_PROXY` is merged with the `no_proxy` key rather than replacing it. Every other setting belongs in the configuration file.
## See also
<CardGroup cols={1}>
<Card title="Remote compute clusters" href="/docs/claude-science/remote-compute-clusters">
Connect an SSH host and run jobs on it.
</Card>
</CardGroup>
claude-science/compute-providers First recorded · 37 lines, first recorded
# Compute providers ## Connecting Modal ## Running cloud jobs ## Container images ## Model endpoints ### NVIDIA BioNeMo NIM
The first capture of this source. The page was already there, and this is what it said.
# Compute providers > Claude Science can run jobs on an external cloud provider you control, and connect to model servers that serve scientific models over HTTP. Claude Science can run jobs on Modal using a Modal account you own and control. You connect your account, jobs run on it, and Modal bills you directly. Anthropic doesn't provide or bill compute and never sees a payment method. ## Connecting Modal In Settings > Compute > **Cloud providers**, click Connect on the Modal card. If you've signed in with the Modal CLI (`modal token new`), the app reads `~/.modal.toml` automatically; click Check again after the file exists. Alternatively, paste a **Token ID** and **Token secret** in Settings > Credentials, under Modal. Tokens are stored encrypted on your computer and never shown to Claude. ## Running cloud jobs When work needs a GPU or more memory than your machine has, Claude proposes a job and a **Start a Modal job?** card appears. The card shows the Modal profile, exact machine spec (for example, H100, 8 CPUs, 32 GiB), a note that billing is per-second, and the maximum billable time. It links to Modal's pricing page. Approve per job, or for the conversation or project. A separate card asks before Claude opens a Modal setup shell (capped at 30 minutes, no GPU). Input files are limited to 1 GiB per submit. For larger inputs, Claude can stage data to a Modal Volume and mount it into the job. Outputs written to `./out/` (up to 5 GiB) are returned with logs. <Note> Closing the app doesn't cancel a running Modal job; it continues billing until it finishes or times out. </Note> Cost controls: there's no spend ceiling. Each job is approved individually with its machine and time limit visible. **Concurrent jobs** (default 10, set on the Modal page under Settings > Compute) caps simultaneous containers that Claude Science on this machine can run. **Default container timeout** is 12 hours (maximum 23), enforced by Modal. Track spend on Modal's dashboard. On the Modal page under Settings > Compute you can set the Modal environment and the default application name used for containers. ## Container images Claude derives a container image from the environment a job needs and builds it once on Modal's build servers, then reuses that image for later jobs until the environment changes. Claude tracks built images in the Details document on the Modal page under Settings > Compute. ## Model endpoints Claude Science can connect to a model server (hosted, or a container you run) that serves a scientific model over HTTP, and call it directly from analyses. ### NVIDIA BioNeMo NIM In Settings > Compute, under Model endpoints, click Connect on NVIDIA BioNeMo NIM. Import the skills from the BioNeMo Agent Toolkit, add your NVIDIA NGC API credential, and connect to NVIDIA-hosted API endpoint, or choose to run the model as a local container (On a machine with an NVIDIA GPU). Once connected, ask Claude to start a local Docker NIM container or set up a remote connection for a specific NIM skill from the BioNeMo Agent Toolkit.
claude-science/configuration-file-reference First recorded · 48 lines, first recorded
# Configuration file reference ## Network configuration ### App connection keys ### Package download keys ### Sandbox network keys ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Configuration file reference > Claude Science's config.toml file: where it lives, how its values interact with the Settings page, and the network-related keys for the outbound proxy, certificate bundles, package mirror, and sandbox network allowlist. Claude Science reads optional settings from a TOML file at `~/.claude-science/config.toml` on macOS and Linux. Every key has a default, so the app starts with no file present; administrators deploy the file with device management to set fleet policy. The file is read once at startup, so changes take effect after a restart. The `claude-science` command accepts `--config <file>` to read a different file for one run. ## Network configuration The network-related keys, grouped by the TOML table each belongs to. For the package-mirror keys (`[conda] channel_mirror`, `pip_index_url`, and `ca_bundle`) and the proxy key (`[network] proxy`), a value set in the file takes precedence over the matching Settings control, which then shows as managed by your organization so a member cannot override it. The `[sandbox.network]` lists are additive instead: they add to the member-managed lists under **Settings** > **Network** and lock nothing. The `[network] ca_bundle`, `no_proxy`, and `mcp_x509_strict` keys and `[conda] allow_insecure_mirror` have no in-app control. ### App connection keys The `[network]` table configures the app's own connections to Anthropic. | Key | Type | Default | Effect | | ----------------- | ------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `proxy` | string (URL) | unset | The outbound proxy for the app's HTTP and HTTPS connections, for example `http://proxy.example.corp:8080`. Supply Basic-authentication credentials in the address. An `https://` (TLS-to-proxy) address applies to the app's own connections only; sandboxed package downloads connect directly when the proxy is `https://`, so prefer `http://`. A proxy variable in the app's environment (including `ALL_PROXY`) takes precedence over this key, which takes precedence over the Settings proxy field and the macOS system proxy settings. | | `no_proxy` | string (comma-separated) | unset | Hosts that bypass the proxy, as exact hostnames or domain suffixes in one comma-separated string, for example `".example.corp,registry.example.corp"`. Combined with the `NO_PROXY` environment variable and, when the macOS system settings supply the proxy address, the system's bypass list. Loopback addresses always bypass the proxy. | | `ca_bundle` | string (absolute path) | unset | PEM file added to the app's default TLS trust for sign-in, the Claude API, Anthropic-hosted connectors, and update checks; use it for a corporate root behind TLS inspection. It covers the app's own connections only, while package downloads use `[conda] ca_bundle`. The value must be an absolute path outside the app's data directory (`~/.claude-science`), temporary directories, and any directory you have granted Claude write access to; a system location such as `/etc/claude-science/corporate-ca.pem` is recommended. The file must exist, parse as a PEM bundle, and contain no private key; a failing value is ignored with a warning. | | `mcp_x509_strict` | `"auto"`, `"relaxed"`, or `"strict"` | `"auto"` | How strictly local connectors check a corporate certificate's profile. With `"auto"`, Claude Science relaxes the strict check when it detects TLS inspection from a configured `[network] ca_bundle`. Connectors pick up a change at their next relaunch. | ### Package download keys The `[conda]` table configures where analysis environments fetch packages from and how those downloads verify certificates. | Key | Type | Default | Effect | | ----------------------- | ---------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `channel_mirror` | string (URL) | unset | Base URL of an internal conda mirror. Channel names resolve beneath it, so `<channel_mirror>/conda-forge/noarch/repodata.json` must return the conda-forge index. Setting it removes the public conda hosts from the sandbox allowlist and admits the mirror host, which environment builds contact directly from the workstation, not through an outbound proxy. Must be `https://` on port 443 or 8443 (an `http://` URL is accepted only when `allow_insecure_mirror` is set), by DNS name, with no embedded credentials. A deployed value these rules reject prevents the app from starting. | | `pip_index_url` | string (URL) | unset | A PEP 503 simple index for Python packages, for example an Artifactory or Nexus PyPI remote ending in `/simple`. Setting it removes the public Python hosts from the sandbox allowlist. Same URL rules as `channel_mirror`, including the startup failure on an invalid value. | | `ca_bundle` | string (absolute path) | unset | A complete PEM bundle (public roots plus your corporate roots) that package downloads verify against, replacing the default trust list; in this release the bundle alone may not be sufficient for pip, which verifies against the operating system's trust store. This key affects package downloads only and never fixes sign-in; behind TLS inspection, set `[network] ca_bundle` as well. When unset, Linux uses your distribution's system certificate bundle. Same path rules as `[network] ca_bundle`. | | `allow_insecure_mirror` | boolean | `false` | Allows `http://` mirror URLs in this file (the Settings page accepts `https://` only). Off by default because a plaintext mirror lets an on-path attacker substitute packages. | ### Sandbox network keys The `[sandbox.network]` table adjusts the network allowlist the analysis sandbox enforces. Members see the same allowlist under **Settings** > **Network**. | Key | Type | Default | Effect | | ----------------- | ---------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `enabled` | boolean | `true` | When `false`, code Claude runs has no network access: package installs and data fetches inside the analysis fail, while the app's own connections are unaffected. This is a no-network mode, not a way to skip the allowlist. | | `allowed_domains` | array of strings | `[]` | Domains added to the built-in allowlist, as exact hostnames or wildcards such as `*.example.org`. | | `denied_domains` | array of strings | `[]` | Domains added to the built-in denylist. A denied domain is blocked even if it also appears on the allowlist, and the built-in denylist entries cannot be removed. | ## Related resources * [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks): how to apply these keys for a proxy, TLS inspection, or an internal mirror * [Network requirements](/docs/claude-science/network-requirements): the built-in allowlist and denylist these keys adjust * [Manage Claude Science on devices](/docs/claude-science/manage-on-devices): deploying `config.toml` with device management * [Command line settings](/docs/claude-science/command-line-settings): the `--config` and `--data-dir` flags
claude-science/connectors-and-skills First recorded · 48 lines, first recorded
# Connectors and skills ## Featured connectors ## Using connectors ## Skills
The first capture of this source. The page was already there, and this is what it said.
# Connectors and skills > Connectors give Claude access to external data sources during an analysis. Connectors give Claude access to external data sources during an analysis. Skills are written instructions Claude loads when relevant, covering how to run a method, which tools to use, and what to verify. Both are managed in Settings and apply across all projects. ## Featured connectors Claude Science includes Featured connectors to public life-sciences databases. All are on by default and can be turned off individually in **Settings > Connectors**. Featured connectors are read-only and don't require an account or key. Some underlying databases have non-commercial or attribution terms; review each source's license for your use case. | Connector | Sources | | ------------------------- | ---------------------------------------------------- | | Genomes | Ensembl (incl. VEP), UCSC | | Genes & Ontologies | MyGene, UniProt, GO, Reactome, OLS | | Variants | gnomAD, ClinVar, dbSNP | | Human Genetics | GWAS Catalog, eQTL Catalogue, FinnGen, BioBank Japan | | Clinical Genomics | ClinGen, CIViC, Open Targets | | Expression | GTEx | | Regulation | ENCODE, JASPAR, UniBind | | Protein Annotation | InterPro, Pfam, Human Protein Atlas, STRING | | Structures & Interactions | PDB, AlphaFold, EMDB, Complex Portal, IntAct | | RNA | Rfam | | Omics Archives | GEO, ArrayExpress, PRIDE, MGnify, MetaboLights | | Cancer Models | cBioPortal | | Chemistry | PubChem, ChEBI, Rhea, BindingDB | | Drug Regulatory | FDA drug data, openFDA | | Literature Graph | OpenAlex, arXiv | | Research Resources | Grants.gov, Antibody Registry | Additional Featured connectors: **BioMart**, **CellGuide** (CELLxGENE cell types), **ZINC** (purchasable chemical space), and **Ketcher Chemistry** (2D molecule sketcher). Four Directory connectors are available from the [connector directory](https://claude.com/connectors) and are accessible in Claude Science and other Claude products: **PubMed**, **Clinical Trials**, **ChEMBL**, and **bioRxiv**. On Team and Enterprise plans, directory connectors appear only after an admin adds them. By choosing to enable connectors, you authorize Claude to use the optional enabled resources on your behalf and confirm you have the necessary rights and licenses. These resources and content they reach may be subject to third-party terms (viewable in Settings), and you are solely responsible for compliance. ## Using connectors Name a source in your request, or describe what you need and Claude chooses from available connector tools. Connector queries appear in the conversation as expandable code steps. Featured connectors you've previously enabled run without a permission card. Connectors you add yourself prompt for approval per tool, with Once, This conversation, This project, or Global scope. The databases behind Featured connectors are on the network allowlist in groups under Settings > Network. Turning off a group disables the connectors that depend on it. ## Skills **Settings > Skills** lists the skills Claude can load. Featured science skills include literature review, indication dossier, and model-specific skills for AlphaFold2, Boltz-2, Chai-1, ESMFold2, OpenFold3, ProteinMPNN (with LigandMPNN and SolubleMPNN), DiffDock, ESM-2, Evo 2, Borzoi, scGPT, and scvi-tools. Claude loads a skill automatically when the work calls for it. Type **/** in the composer to open the skill picker and insert one explicitly. **Add skill** lets you create your own via **Chat with Claude**, **Write from scratch**, **Upload a skill**, or **Import from GitHub**. **Import from GitHub** works with private repositories too, once you add a GitHub token under **Settings > Credentials**. You can also ask Claude to distill a workflow from an existing session into a skill.
claude-science/core-concepts First recorded · 57 lines, first recorded
# Core concepts ## Projects and sessions ## Files stay on your computer ## Permission cards ## Plans ## Sandbox ## Delegation ## Memory ## Composer shortcuts
The first capture of this source. The page was already there, and this is what it said.
# Core concepts > A project groups related sessions and the artifacts they produce. ## Projects and sessions A project groups related sessions and the artifacts they produce. Projects also let you set up custom instructions for Claude to read at the start of every session. Folder permissions you grant persist across sessions within a project. A session is one conversation thread. Each session has its own workspace folder and multiple running kernels. ## Files stay on your computer Claude reads and writes files in place, in the folders you grant. Anthropic doesn't host or store your files; file content that Claude reads to answer a prompt is sent to Anthropic's API as part of that conversation and handled under Anthropic's standard retention policy. If you sign in to Claude Science on a different computer, your files, artifacts, and conversation history don't follow you there. The one exception to working in place is **Attach files** in the composer: attached files are copied into the application's local data folder so they stay with the conversation. <Warning> Don't move, rename, or delete files inside \~/.claude-science directly. Doing so can break artifact links and version history. Manage artifacts through the app. </Warning> ## Permission cards A permission card appears in the conversation each time Claude needs a new kind of access. The card names exactly what's being requested. You can allow or deny each one. | Action | Card title | Scope options | | ---------------------- | ----------------------------------------------------------- | ------------------------------------------------- | | Read or write a folder | Access `<folder>` on your computer? | Read-only or Read & write; persists until revoked | | Run code | Run Python code? / Run a shell command? / Install packages? | Once or Always | | Reach a network host | Connect to `<target>`? | Persists until revoked | | Use a connector tool | Use `<tool>`? | Once, This conversation, This project, or Global | | Run a remote job | Run this job on `<host>`? / Start a Modal job? | Once, This conversation, This project, or Global | All standing grants are listed in Settings > Permissions and can be revoked there. ## Plans Claude might choose to propose a plan before starting multi-step work. You approve the plan or iterate with Claude on refining it; plan text can't be edited directly. Approved plan steps appear in the conversation and are marked complete as work finishes. ## Sandbox All code Claude writes runs inside an operating-system sandbox on your computer. The sandbox can read and write only the workspace and the folders you've granted. Its network is deny-by-default: outbound connections go through a local proxy that allows only package managers, the scientific databases behind Featured connectors, and hosts you've approved. ## Delegation **Delegation** lets Claude split a request into independent tracks that run in parallel. Turn it on or off per session in the session settings menu; your last choice becomes the default for new sessions. When work splits, a marker appears in the conversation for each track with a status indicator. Click a marker to open that track's transcript. **Stop** ends the whole session; individual tracks can't be stopped separately. ## Memory Memory lets Claude save short facts about you, your projects, and your files across sessions. Memory is off by default. Turn it on in Settings > Memory. Saved facts are stored in the app's local database on your computer; they aren't synced to Anthropic. The Memory settings page lists every saved fact. You can edit, delete, add, or clear facts there. A per-session toggle in the session settings menu turns memory off for that session only. ## Composer shortcuts * `@` inserts an artifact or uploaded file by name * `#` inserts a past session by title * `/` inserts a skill
claude-science/corporate-networks First recorded · 216 lines, first recorded
# Use Claude Science on a corporate network ## Setup at a glance ## What works on a corporate network ## Point package installs at an internal mirror ### Mirror credentials ### Mirror traffic and your other network controls ## Connect through an outbound proxy ### Proxy settings in the configuration file ### macOS system proxy settings ### How the environment variables reach the app ## Work behind TLS inspection ### Corporate root for app connections ### Corporate root for package downloads ### What the certificate settings do not cover ## Troubleshooting corporate network errors ### Token exchange failed: unable to get local issuer certificate ### The proxy requires its own sign-in (HTTP 407) ### Package downloads are being blocked by network policy ### HTTP 401 or 403 during an environment build ### HTTP 401 on the mirror check ### Green check, then nothing provides the package ### CONNECT tunnel failed, response 403, naming an amazonaws.com host ### https mirrors must use port 443 or 8443 ### Local connectors fail with certificate errors behind inspection
The first capture of this source. The page was already there, and this is what it said.
# Use Claude Science on a corporate network
> How to run Claude Science behind an outbound proxy, a TLS-inspecting proxy, an internal package mirror, and an egress firewall, with the settings your network team needs for each.
Claude Science runs on each member's computer and connects out for sign-in, the Claude API, and package and research hosts, usually through controls your IT organization manages on a corporate network. This page shows the administrator who runs those controls how to point Claude Science at an internal package mirror, configure an outbound proxy and TLS inspection, and hand the firewall team the [network requirements](/docs/claude-science/network-requirements) it needs.
Claude Science makes three kinds of outbound connections, each passing through a different part of your network policy:
* The app's own connections (sign-in, the Claude API, Anthropic-hosted connectors, update checks) traverse your outbound proxy and TLS inspection.
* The analysis sandbox's connections (package hosts and research databases, when Claude runs code) are filtered by the app's own network allowlist; package downloads can be redirected to your internal mirror.
* Interactive previews load display libraries from public content-delivery networks in the browser, as ordinary browser traffic governed by your endpoint's web policy.
## Setup at a glance
1. Check the [support table](#what-works-on-a-corporate-network) for your operating systems and network shape.
2. Hand the [network requirements](/docs/claude-science/network-requirements) page to the team that manages your proxy or firewall allowlist.
3. [Point package installs at your internal mirror](#point-package-installs-at-an-internal-mirror) if the public package hosts are blocked, and deploy the mirror credential.
4. [Connect through an outbound proxy](#connect-through-an-outbound-proxy) if your network uses one.
5. If your proxy inspects TLS, [deploy your corporate root certificate](#work-behind-tls-inspection) as two bundles: one for the app, and a differently built one for package downloads.
6. [Deploy the settings with device management](/docs/claude-science/manage-on-devices#deploy-configuration-with-device-management) rather than by hand.
7. If sign-in or a first build fails, match the error against [Troubleshooting](#troubleshooting-corporate-network-errors).
## What works on a corporate network
| Network shape | macOS | Linux |
| ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Explicit outbound HTTP proxy (HTTP CONNECT) | Supported; detected automatically from the system settings | Supported |
| Proxy that requires Basic authentication | Supported, with credentials in the proxy address | Supported, with credentials in the proxy address |
| Proxy that requires NTLM, Negotiate, or Kerberos authentication | Not supported | Not supported |
| Network that only publishes a PAC or WPAD file | Not supported | Not supported |
| SOCKS proxy | Not supported | Not supported |
| TLS inspection on the app's own connections (Zscaler, Netskope, and similar) | Supported with a CA bundle setting | Supported with a CA bundle setting |
| TLS inspection on conda package downloads | Supported with a CA bundle setting | Supported with a CA bundle setting |
| TLS inspection on pip package downloads | Supported, with the corporate root also installed in the operating system's trust store (see [Corporate root for package downloads](#corporate-root-for-package-downloads)) | Supported, with the corporate root also installed in the operating system's trust store (see [Corporate root for package downloads](#corporate-root-for-package-downloads)) |
| Internal package mirror (Artifactory, Nexus) | Supported | Supported |
| Internal package mirror reached only through the corporate proxy | Not supported | Not supported |
| Authenticated package mirror | Supported, with the credential saved in Settings | Supported, with the credential saved in Settings |
| Local connectors (the bundled research tools) behind TLS inspection | Not supported | Not supported |
## Point package installs at an internal mirror
When your network blocks the public package hosts (`conda.anaconda.org`, `repo.anaconda.com`, `pypi.org`), point Claude Science at your internal artifact repository instead, and every environment build fetches packages through it. Set the mirror for a fleet with the `[conda] channel_mirror` and `pip_index_url` keys in a [deployed `config.toml`](/docs/claude-science/manage-on-devices#deploy-configuration-with-device-management), or for a single machine under **Settings** > **Network** > **Package mirror**, where the same two settings are called the conda channel mirror and the pip index URL. The steps below use the Settings page, the quickest way to test a mirror URL before you deploy it.
Set both a conda channel mirror and a pip index: analysis environments are built from conda packages, so a pip index alone leaves the first build stuck trying to reach the public conda host.
<Steps>
<Step title="Enter the conda channel mirror">
Open **Settings** > **Network**, select **Configure** on the **Package mirror** row, and paste the base URL of your conda mirror. For JFrog Artifactory that is the conda API root or a virtual conda repository, for example `https://yourorg.jfrog.io/artifactory/api/conda/conda-all`.
</Step>
<Step title="Enter the pip index URL">
Paste your Python package index, including the `/simple` suffix that Artifactory and Nexus PyPI remotes use, for example `https://yourorg.jfrog.io/artifactory/api/pypi/pypi-remote/simple`.
</Step>
<Step title="Save, then run the check">
Select **Save**, then **Check**: a green result confirms the mirror answered, and a `401` or `403` on an authenticated mirror is expected until a credential is saved (see [Mirror credentials](#mirror-credentials)). The mirror takes effect for the next package operation without a restart. On a machine with an outbound proxy, confirm with a test environment build rather than the check alone (see [Mirror traffic and your other network controls](#mirror-traffic-and-your-other-network-controls)).
</Step>
</Steps>
The mirror must serve the standard conda channel layout, with one base URL, one directory per channel, and one per platform beneath it:
```text theme={null}
<channel mirror>/
conda-forge/
noarch/repodata.json
noarch/<package>.conda
linux-64/repodata.json
osx-arm64/...
bioconda/
noarch/...
```
Your mirror must serve at least `conda-forge` (every environment uses it) and `bioconda` for R and bioinformatics work; other channels a member requests (for example `pytorch` or `nvidia`) resolve under the same mirror base, so serve those too if needed. Anaconda's commercial `defaults` channel is rejected while a mirror is configured, so members should use `conda-forge` instead.
<Note>
Do not point the conda mirror at a remote repository configured for a single channel (for example one whose upstream is `https://conda.anaconda.org/conda-forge`): it returns an empty index that the check reports green while every build then fails with `nothing provides <package>`. Use a remote that proxies the conda host root (`…/artifactory/api/conda/conda-remote`), a virtual conda repository, or the conda API root with channel-named remote repositories beneath it.
</Note>
Mirror URLs must use `https://`, name a host by DNS name rather than IP address, and use port 443 or 8443, so an Artifactory instance on its stock port 8081 needs a 443 or 8443 listener or a reverse proxy in front of it. Credentials embedded in the URL are rejected at save time. The Settings page accepts `https://` mirrors only, while Claude Science also accepts an `http://` mirror from `config.toml` when `[conda] allow_insecure_mirror` is set. Validate mirror URLs before distributing a `config.toml`, since an invalid deployed value prevents the app from starting.
### Mirror credentials
For a mirror that requires authentication, enter one username and access token under **Settings** > **Network** > **Package mirror** > **Mirror credentials**, using an account scoped to reading the mirror, then run the check so it signs in with the credential. The one credential is presented to both the conda-mirror host and the pip-index host, so if those need different accounts, keep one of them anonymous; the credential is sent only to `https://` mirror hosts.
Claude Science stores the credential encrypted in its local database, using a key kept in a file only the member's account can read (on macOS, a copy of that key is in the keychain for recovery), and also writes the credential, automatically, to a plaintext `.netrc` at `~/.claude-science/conda/.netrc` that the conda and pip download tools read during environment builds. Code that runs while an environment builds (a package's `setup.py`, for example) can read that file, Claude's analysis code cannot read either location, and a `.netrc` in the member's home directory is not used for these downloads. For a fleet that manages credentials centrally, deploy that `.netrc` file yourself instead, one `machine <mirror hostname>` block per mirror host with `login` and `password` lines and no comments, and use either the file or Settings, not both: a credential saved in Settings rewrites the file from the saved value at the save and at every restart and environment build, while a file deployed with no credential saved in Settings is left alone.
Environments a member registers from an existing project folder install their packages inside the analysis sandbox during a session, where the credential is hidden by design, so those environments need a mirror that allows anonymous reads.
### Mirror traffic and your other network controls
Configuring a mirror removes the public package hosts from the sandbox's network allowlist and admits the mirror host in their place, so a misconfigured mirror fails with an error that names the mirror rather than falling back to the public hosts. To keep the public hosts reachable alongside the mirror, re-add them under **Settings** > **Network** (`pypi.org`, `*.pypi.org`, `files.pythonhosted.org` for pip, and `conda.anaconda.org`, `repo.anaconda.com`, `anaconda.org`, `*.anaconda.org` for conda).
Environment builds connect to the mirror host directly, never through your outbound proxy: the workstation needs a direct route (typically your VPN or internal network), any workstation firewall must allow the mirror host as a direct destination, and a proxy allowlist entry alone does not reach it. A package failure that names the mirror on a proxy-only network therefore means the mirror is unreachable directly, and a SaaS repository such as `yourorg.jfrog.io` works only if the workstation can reach it directly, so on a proxy-only network host the mirror inside your network. On a proxy-configured machine the **Check** button and a real build can take different paths, so treat a test environment build as the authoritative signal (a known limitation).
Mirrors that redirect package files to path-style object-storage URLs (such as `s3.us-west-2.amazonaws.com/<bucket>/...`) fail with `CONNECT tunnel failed, response 403`, because path-style object-storage hosts are on a built-in denylist that cannot be overridden; have the mirror serve the files itself, or redirect to bucket-qualified hostnames such as `<bucket>.s3.us-west-2.amazonaws.com` and add that hostname under **Settings** > **Network** > **Allowed domains**. The check warns at save time when it sees a redirect to a denied host. The package manager that builds environments ships inside the app, so a first build on a locked-down network downloads no tooling from GitHub.
## Connect through an outbound proxy
Claude Science reads its proxy configuration once at startup, so restart it after a change. The first source that sets a proxy address wins:
1. The standard proxy variables in its own process environment: `HTTPS_PROXY`, `HTTP_PROXY`, and `NO_PROXY` (lowercase spellings also work). `ALL_PROXY` fills in for either proxy variable that is unset, an empty variable counts as unset, and `NO_PROXY="*"` sends all traffic directly.
2. The `[network] proxy` key in `config.toml`, the form to [deploy with device management](/docs/claude-science/manage-on-devices#deploy-configuration-with-device-management).
3. The proxy field under **Settings** > **Network**, where a member can paste a proxy address by hand. It takes effect at the next restart, and when `config.toml` sets the proxy, the field shows as managed by your organization so members cannot override it.
4. On macOS only, an explicit web proxy configured in the system's network settings, which Claude Science detects automatically.
Write the proxy as an `http://` URL; if it requires a username and password, embed them in the address and percent-encode special characters (for example, `@` in a password becomes `%40`):
```text theme={null}
HTTPS_PROXY=http://username:[email protected]:8080
HTTP_PROXY=http://username:[email protected]:8080
NO_PROXY=.example.corp
```
An `https://` (TLS-to-proxy) address works for the app's own connections only. Sandboxed package downloads tunnel only through `http://` proxies, so with an `https://` address they skip the proxy and connect directly; an `http://` address keeps every connection on the proxy.
Claude Science always bypasses the proxy for loopback addresses (`localhost`, `127.0.0.1`, and their IPv6 equivalents), whether or not they appear in `NO_PROXY`, so the app and its background service can always talk to each other. Add your internal domains to `NO_PROXY`; entries match a host exactly or as a domain suffix (`.example.corp` and `example.corp` behave the same), and CIDR ranges such as `10.0.0.0/8` are not matched. `NO_PROXY` entries from the environment, the configuration file, and (when the system settings supply the proxy address) the macOS bypass list are combined.
### Proxy settings in the configuration file
For a fleet, set `[network] proxy` and `no_proxy` in `config.toml`; both keys and their formats are in the [configuration file reference](/docs/claude-science/configuration-file-reference#app-connection-keys).
### macOS system proxy settings
Claude Science detects an explicit system web proxy automatically, so a machine whose proxy your MDM already sets needs no Claude Science configuration unless the proxy requires authentication. macOS keeps an authenticated proxy entry's credentials in the keychain, where Claude Science cannot read them, so connections through the detected proxy fail with HTTP 407 (see [the troubleshooting entry](#the-proxy-requires-its-own-sign-in-http-407)); set `[network] proxy` with the credentials in the address instead. When the network publishes only a PAC or WPAD file, Claude Science detects it and names the PAC URL in the sign-in error, but does not evaluate it. Set `[network] proxy` to the proxy the PAC file resolves to for Anthropic's hosts.
### How the environment variables reach the app
How the variables reach the app depends on the operating system:
* On macOS, the menu-bar app reads `~/.claude-science/env`, a file of `KEY=VALUE` lines (`export KEY=VALUE` also works), when it launches. Put the three variables there, then quit and reopen the app; an app started from the Dock or Finder does not see variables exported in a terminal. The file's `NO_PROXY` entries merge with the other sources rather than replacing them.
* On Linux, export the variables in the shell or service unit that starts `claude-science serve`. The `env` file is read only by the macOS app.
Only Basic proxy authentication, supplied in the proxy address, is supported; NTLM, Negotiate, and Kerberos proxies are not, and neither are networks whose only published proxy configuration is a PAC or WPAD file, because Claude Science does not evaluate PAC files.
<Note>
For a proxy that only speaks NTLM or Kerberos, a local relay such as `cntlm` or `px` works: the relay runs on the workstation, authenticates to your corporate proxy with the user's credentials, and exposes a plain HTTP proxy on the loopback interface. Point `HTTPS_PROXY` and `HTTP_PROXY` at the relay (for example `http://127.0.0.1:3128`). The loopback bypass governs which destinations skip the proxy, not whether the proxy can be reached, so a loopback relay works as a proxy address.
</Note>
Environment builds reach a configured [package mirror](#point-package-installs-at-an-internal-mirror) directly, not through the proxy. Separately, the `claude-science update` terminal command is its own process: it honors proxy variables exported in that shell but not the macOS `env` file, so export the variables in the terminal first. The background updater inside the running app uses the app's proxy settings.
## Work behind TLS inspection
A TLS-inspecting proxy such as Zscaler or Netskope re-signs every HTTPS connection with a certificate from your organization's own root certificate authority, which Claude Science's built-in list of public roots does not include, so until you give it that root, sign-in and package downloads fail certificate verification (the sign-in error is listed under [Troubleshooting](#troubleshooting-corporate-network-errors)).
Two settings carry the corporate root and behave differently. Set the one that matches the traffic, and read the warning in [Corporate root for package downloads](#corporate-root-for-package-downloads) before reusing one file for both.
### Corporate root for app connections
The `[network] ca_bundle` key in `config.toml` points at a PEM file whose certificates Claude Science adds to its default trust for sign-in, the Claude API, Anthropic-hosted connectors, and update checks; the public roots stay in place, so the file holds only your corporate root. The path rules are in the [configuration file reference](/docs/claude-science/configuration-file-reference#app-connection-keys). A failing value is ignored with a warning rather than stopping the app, so a sign-in error behind inspection usually means the bundle did not load, and the app re-reads the bundle every few minutes, so a corrected file takes effect without a restart. When you deploy a `config.toml`, deploy the bundle files alongside it.
### Corporate root for package downloads
Conda package downloads for the analysis sandbox use their own setting, `[conda] ca_bundle`, the complete list of roots those downloads trust, so it must contain the public roots your packages come from as well as your corporate root. On Linux, when the key is not set, Claude Science uses your distribution's system certificate bundle (maintained by `update-ca-certificates` or `update-ca-trust`), so a Linux image that already trusts your corporate root needs no setting at all.
`[conda] ca_bundle` affects package downloads only and never fixes sign-in. The CA bundle path field on the Settings page sets this same `[conda]` key, so filling it in helps package downloads only. Behind TLS inspection you also need `[network] ca_bundle`, which has no Settings field and is set in `config.toml`.
pip verifies package downloads against the operating system's trust store, and in this release setting `[conda] ca_bundle` alone may not be sufficient for pip, so also install the corporate root in that trust store: on Linux with `update-ca-certificates` or `update-ca-trust`, and on macOS in the system keychain through your MDM.
```toml theme={null}
[conda]
ca_bundle = "/etc/claude-science/complete-bundle.pem"
```
The same path rules apply as for `[network] ca_bundle`; the [configuration file reference](/docs/claude-science/configuration-file-reference#package-download-keys) lists them.
<Warning>
Do not point `[conda] ca_bundle` at the single-root file you use for `[network] ca_bundle`: the package-download setting replaces the whole trust list, so a file containing only your corporate root breaks every package download on any network your proxy does not inspect, such as a laptop on home Wi-Fi. Build the `[conda]` bundle from your system's public roots plus the corporate root.
</Warning>
### What the certificate settings do not cover
Code that Claude runs inside a session, such as a `pip install` typed into a cell or an R `install.packages()` call, does not see either bundle; behind TLS inspection, have Claude install packages into an environment rather than in a cell.
The local connectors (the bundled research tools) do not work behind TLS inspection in this release: they run in their own Python environment, and nothing delivers your corporate root to that environment, so their connections fail certificate verification. This is a known limitation. Claude Science does detect TLS inspection from your configured CA bundle and relax the connectors' strict certificate-profile check, which stops them from rejecting a corporate root whose Basic Constraints extension is not marked critical, but that relaxation adds no trust. The Anthropic-hosted connectors keep working once `[network] ca_bundle` is set. Connector installs that use `npm` also keep npm's own certificate configuration.
Voice dictation's server-side speech recognition uses a WebSocket connection that is covered by neither the certificate settings nor the proxy settings, so it does not work behind TLS inspection or a mandatory proxy; in the browser, dictation falls back to the browser's own speech recognition.
Certificate environment variables set in a shell, such as `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, or `PIP_CERT`, never reach package downloads, because those run in an isolated environment. Use the `ca_bundle` keys instead.
## Troubleshooting corporate network errors
### Token exchange failed: unable to get local issuer certificate
Sign-in completes in the browser, then fails with this error when Claude Science's own connection to Anthropic hits TLS inspection without trusting your corporate root. The member sees a notice that the network inspects secure connections, with this error beneath it. Set `[network] ca_bundle` to a PEM file containing your corporate root (see [Corporate root for app connections](#corporate-root-for-app-connections)) and confirm the bundle warning is gone from the app log (`claude-science logs` prints it).
### The proxy requires its own sign-in (HTTP 407)
Sign-in fails with this message when the proxy demands credentials the app is not sending, because the proxy address carries none or the proxy was detected from the macOS system settings, which never supply credentials. Include the Basic-authentication credentials in the proxy address (percent-encoding special characters) under **Settings** > **Network** > **Proxy address**, in `[network] proxy`, or in `HTTPS_PROXY`, then restart the app. Only Basic authentication works, so a proxy that requires NTLM, Negotiate, or Kerberos cannot be satisfied this way. During an environment build, a proxy authentication failure surfaces as a generic HTTP 502 error rather than a 407 message.
### Package downloads are being blocked by network policy
An environment build reports this (often with HTTP 502) when it tries to reach the public package hosts on a network that blocks them and no mirror is configured. Configure the mirror under **Settings** > **Network** > **Package mirror**, with both the conda channel mirror and the pip index set.
### HTTP 401 or 403 during an environment build
The mirror requires authentication and the build is not presenting a credential it accepts. Check that a credential is saved under **Settings** > **Network** > **Package mirror** > **Mirror credentials** (or, on a fleet that deploys the `.netrc` file directly, that the file has a block for the exact mirror hostname); a credential in `~/.netrc` in the home directory is ignored for these downloads.
### HTTP 401 on the mirror check
With no saved credential, a `401` is expected because the check sends none; enter the credential under **Mirror credentials** and run the check again. When a credential is saved, the check signs in with it, so a `401` means the token is wrong or expired. On a proxy-configured machine the check and a build can also take different network paths (see [Mirror traffic and your other network controls](#mirror-traffic-and-your-other-network-controls)).
### Green check, then nothing provides the package
The conda mirror URL points at an Artifactory remote repository configured for a single channel, which returns an empty index that the check accepts; see the note in [Point package installs at an internal mirror](#point-package-installs-at-an-internal-mirror) for the mirror URL forms that work.
### CONNECT tunnel failed, response 403, naming an amazonaws.com host
The mirror redirects package files to path-style cloud object storage, which the sandbox blocks. Switch the mirror to serve the files itself or to use bucket-qualified storage URLs, as described in [Mirror traffic and your other network controls](#mirror-traffic-and-your-other-network-controls).
### https mirrors must use port 443 or 8443
The mirror is listening on a port the sandbox cannot tunnel to. Put a 443 or 8443 listener or a reverse proxy in front of it, then save the `https://` URL again.
### Local connectors fail with certificate errors behind inspection
The local research connectors report certificate failures, while the Anthropic-hosted connectors keep working once `[network] ca_bundle` is set, because the corporate root does not reach the local connectors' own Python environment (see [What the certificate settings do not cover](#what-the-certificate-settings-do-not-cover)). This is a known limitation on TLS-inspected networks.
claude-science/custom-connectors First recorded · 15 lines, first recorded
# Custom connectors
The first capture of this source. The page was already there, and this is what it said.
# Custom connectors > Add any Model Context Protocol (MCP) server as a Remote (HTTPS web server) or Local command (program on your computer). In **Settings > Connectors** > **Add connector**, choose Remote or Local command and enter a **Name** (lowercase letters, digits, hyphens). For Remote, enter the server URL; Advanced settings covers transport (**SSE** or **Streamable HTTP**), OAuth client settings, and the **Headers helper command**. For Local command, enter the command; Advanced settings covers arguments and environment variables. **Browse Connectors Directory** opens the public directory. Remote servers that need login take you through the provider's sign-in page. Every tool from a custom connector starts at **Ask each time**. On the connector's page, set individual tools to **Always allow** or **Block** under **Tools**, or turn on Skip approvals for the whole connector. <Warning> Skip approvals disables the per-call card for every tool on that connector. Only use connectors from developers you trust. </Warning> Local-command connectors run inside the sandbox with the same network limits as Claude's code and a per-connector writable directory. Environment variables for local connectors are saved unencrypted in a configuration file readable by your account only; don't put high-value secrets there.
claude-science/enable-claude-science First recorded · 69 lines, first recorded
# Enable Claude Science ## Availability ## Turn on Claude Science ### Reviewing role access ### Setting up connectors for the organization ## Who gets access after you enable ## What members see ## HIPAA organizations ## Turn off Claude Science
The first capture of this source. The page was already there, and this is what it said.
# Enable Claude Science > Claude Science is a desktop app for scientific research. Claude Science is a desktop app for scientific research. It's off by default for Team and Enterprise organizations. Turning it on in Organization settings > Claude Science walks you through a short setup wizard that covers what's not supported yet, which roles get access, and which connectors to publish. ## Availability Claude Science is in beta. | Plan | Claude Science app access | | ----------- | ------------------------------------- | | Team | Off; turn on in Organization settings | | Enterprise | Off; turn on in Organization settings | | Pro and Max | On; no admin action needed | | Free | Not available | If your organization has HIPAA compliance enabled, Claude Science app access is also off by default. You can turn it on, but usage isn't covered under your Business Associate Agreement (BAA) and the app shouldn't be used with protected health information (PHI). ## Turn on Claude Science Go to Organization settings > Claude Science.\ Turn on the Enable for your organization toggle. The setup wizard opens.\ Complete each step of the wizard, then select Enable Claude Science.\ Members with access can [download Claude Science](https://claude.com/product/claude-science) and sign in with their claude.ai account. You need an Owner or Primary Owner role to turn Claude Science on or off. If you have the Admin role, you can add members and assign seats, but you can't turn on Claude Science. Ask an Owner or Primary Owner to turn it on. ### Reviewing role access This step appears only on Enterprise plans. It lists any custom roles that already include the Claude Science capability. Built-in roles get access automatically. To change which custom roles have access, select Configure in role settings, or continue and adjust roles later. ### Setting up connectors for the organization Enable the data sources your team will use in Claude Science. Featured connectors are built by Anthropic and curated for scientific research.\ Local connectors ship with the app and run on each member's computer. Members can turn individual local connectors off in the app.\ Directory connectors are additional life sciences connectors from the Claude connector directory. On Team and Enterprise plans, these appear only after an Owner adds them to the organization's connector allowlist. This step is shown read-only if your organization has HIPAA compliance enabled. Add connectors from Organization settings > Connectors after enabling. By continuing, you authorize your team to let Claude use the optional enabled resources on their behalf. These resources and content they reach may be subject to third-party terms (viewable in Settings), and your users are solely responsible for compliance. ## Who gets access after you enable Turning on the organization toggle controls whether Claude Science is accessible to your organization at all. Adding members or assigning seats doesn't turn it on. Once it's on, roles control which members can use it: Built-in roles include the Claude Science entitlement, so those members can download and sign in immediately.\ Custom roles (Enterprise plans only) need the Claude Science capability added. Members on a custom role without the capability see the app as unavailable even after you enable it for the organization.\ A custom role whose Capability access setting is All capabilities already includes Claude Science. The All generally available setting excludes beta capabilities such as Claude Science, so for those roles also select the Claude Science capability. This is the same pattern as other Claude apps you enable per organization. ## What members see Once Claude Science is enabled and a member's role includes the entitlement, they can download the app from claude.com/product/claude-science and sign in with their claude.ai account. If the organization toggle is off, claude.ai stops members at sign-in with a message such as "Claude Science has not been enabled for your account. Contact your organization administrator." On Enterprise plans, members whose custom role doesn't include the capability are stopped the same way. Members who belong to more than one organization on claude.ai, such as a personal account alongside yours, need to choose your organization when claude.ai asks which one to connect. Before they select Authorize, they can also select Switch organization on the authorization screen to change that choice. A member who connects a Free personal account instead sees "Claude Science requires a Pro or Max subscription." and can select Switch account to sign in again and choose your organization. ## HIPAA organizations Organizations with HIPAA compliance enabled can turn on Claude Science during the beta, but usage isn't covered under your BAA. The setup wizard shows this notice on step 1, and the connectors step is read-only because the wizard's quick-enable path doesn't include the per-connector HIPAA attestation. Add connectors from Organization settings > Connectors instead, where the attestation is required. ## Turn off Claude Science Go to Organization settings > Claude Science and turn off the Enable for your organization toggle. Members can no longer sign in to the app. Data already on members' computers stays there; see [How Claude Science works with your data](/docs/claude-science/how-claude-science-works-with-your-data) for details.
claude-science/get-started First recorded · 58 lines, first recorded
# Get started ## Install ## Sign in and complete setup ## Run your first analysis ## Troubleshooting first launch
The first capture of this source. The page was already there, and this is what it said.
# Get started
> Install Claude Science on macOS or Linux, sign in with your Claude account, and run your first analysis.
## Install
macOS: Download the installer from claude.com/product/claude-science and double-click to install. On first launch, the app sets up its runtime and starter Python and R environments, which takes a few minutes, then opens a new tab in your default browser. If no browser tab appears, choose Open from the menu bar icon.
<Note>
Although Claude Science opens in a browser tab, it's a local application, not a website: there's no public URL to visit. Open it from the application itself, with the menu bar icon on macOS or the `claude-science` command on Linux. On a remote server, the sign-in link reaches your browser through an SSH tunnel; see [Run on a remote Linux server](/docs/claude-science/run-on-remote-linux-server).
</Note>
Linux: install the sandbox dependencies, then run the installer. The sandbox needs bubblewrap 0.8.0 or later and socat, and installing them takes administrator (`sudo`) access; if you don't have it, ask your system administrator to install them.
* Ubuntu or Debian: `sudo apt-get update && sudo apt-get install -y curl bubblewrap socat`
* Fedora or RHEL: `sudo dnf install -y curl bubblewrap socat`
* Arch: `sudo pacman -S curl bubblewrap socat`
Ubuntu 24.04's repositories carry a new enough bubblewrap and Ubuntu 22.04's don't; on any distribution, confirm with `bwrap --version` that the installed version is 0.8.0 or later before you start Claude Science.
```bash theme={null}
curl -fsSL https://claude.ai/install-claude-science.sh | bash
```
```bash theme={null}
claude-science serve
```
First launch prints a local URL right away, then continues setting up its starter Python and R environments. To run Claude Science on a remote server and use it from your computer, see [Run on a remote Linux server](/docs/claude-science/run-on-remote-linux-server).
## Sign in and complete setup
When the app opens in your browser, sign in with your Claude account. If the OAuth redirect can't return to the app (for example, through an SSH tunnel), use the Paste a code option on the sign-in screen instead. No API key is required.
After sign-in, a setup wizard walks you through enabling connectors and skills and setting which websites Claude can access. You can change these at any time in Settings.
<Note>
Claude Science keeps all of its data in a single folder (`~/.claude-science`) in your home directory; on Linux, the `claude-science` command itself installs to `~/.local/bin`. It doesn't modify your existing conda installation, R libraries, or shell configuration.
</Note>
<Warning>
Deleting that folder removes all projects, artifacts, and conversation history. Deleting the folder and the application removes Claude Science entirely.
</Warning>
## Run your first analysis
* Open the Example project, or create a new one.
* Start a conversation. Reference a folder on your computer by typing its path or using the @ picker in the composer.
* Review the folder-access card when it appears and choose whether to allow it.
* Review the code-execution card when Claude proposes running code and choose whether to allow it.
* Results appear as artifacts in the Files panel.
## Troubleshooting first launch
* macOS says the application isn't supported, or the app icon appears crossed out: the download page picked the build for the wrong processor. Return to the download page and choose Mac (Intel) or Mac (Apple Silicon) to match your Mac. To check which you have, open the Apple menu, choose About This Mac, and look at the Chip or Processor line.
* No browser tab appeared: on macOS, choose Open from the menu bar icon. On Linux, copy the printed URL into a browser on the same machine, or run `claude-science url` to print a fresh one.
* Linux refuses to start: a sandbox dependency is missing (install bubblewrap and socat as shown in the Install section), too old, or blocked. Check your bubblewrap version with `bwrap --version`, then match the error message to its fix in the [Linux troubleshooting table](/docs/claude-science/run-on-remote-linux-server#troubleshooting).
* Sign-in stops at claude.ai: your account is on the Free plan (upgrade required), the redirect couldn't return (use Paste a code), or your Team or Enterprise organization hasn't [enabled Claude Science](/docs/claude-science/enable-claude-science) yet.
claude-science/glossary First recorded · 51 lines, first recorded
# Glossary
The first capture of this source. The page was already there, and this is what it said.
# Glossary > One-sentence definitions for the terms you meet in Claude Science, from annotation to workspace. One-sentence definitions for the terms you meet in Claude Science, from annotation to workspace. **[Annotation](/docs/claude-science/annotations)**: a comment you pin to part of an artifact by selecting it; Claude reads pending annotations as instructions on its next turn. **[Artifact](/docs/claude-science/artifacts)**: any file Claude makes and saves for you, listed in its session's Files view. **Cell**: one block of code Claude runs in a kernel; the cell, its output, and the environment it ran in are recorded in the session's Notebook. **Cloud provider**: your own account at a cloud service where Claude can start jobs; you pay that provider directly. **Connector**: an outside data source or tool wired into Claude over MCP; Claude Science includes a featured set, you can access partner connectors from the Connectors Directory, and you can add your own under Settings > Connectors. **Data directory**: the `~/.claude-science` folder on your computer holding the database, artifacts, session workspaces, and logs. **[Environment](/docs/claude-science/tools-and-environments)**: a named set of installed packages (conda) that a kernel runs in, reused across sessions. **Execution log**: the slice of a session's Notebook cells that produced a given artifact version, shown as a tab in its Provenance pane. **Kernel**: the live Python or R process that runs a session's cells and keeps variables in memory between them. **Memory**: notes Claude keeps about you and your projects across sessions, which you can review and edit. **Model endpoint**: a scientific domain-specific model server you register under Settings > Compute, that runs locally or connects to a vendor's hosted solution, that Claude sends single prediction requests to. **Network allowlist**: the list under Settings of every outside host that sandboxed code may reach. **Permission card**: the card that replaces the message box when Claude needs your permission for running code, running a job, accessing a network host, a folder, a connector tool, or re-configuring Claude Science; you allow or deny it. **Provenance (the artifact record)**: the panel behind every artifact version showing the code, cells, conversation, environment, and findings that produced it. **[Reviewer](/docs/claude-science/the-reviewer)**: the independent agent that re-examines Claude's claims and artifacts at checkpoints, recording each issue it raises as a finding on the artifact's Review tab; on some plans it runs in the background automatically. **Sandbox**: the isolated environment all of Claude's code runs in; reaching outside it needs your approval. **Scope**: how long an approval lasts (Once, This conversation, This project, or Global), with every standing grant listed and revocable under Settings > Permissions. **Session**: one conversation thread inside a project, with its own kernel and workspace. **Skill**: an installable package of instructions and helper code that teaches Claude a method or tool. **Specialist**: a named set of skills, connectors, and instructions that a session answers as. **SSH host**: a remote machine (server, cluster node, or a job submission host) added by its SSH name, that Claude can run jobs on, or dispatch jobs from. **Version**: one immutable save of an artifact; saving again adds a new version on top instead of overwriting. **Workspace**: the per-session folder on disk where Claude's code reads and writes files before they are saved as artifacts.
claude-science/how-claude-science-works-with-your-data First recorded · 21 lines, first recorded
# How Claude Science works with your data ## What Anthropic receives ## Remote compute ## Connectors ## What this means for you as an admin
The first capture of this source. The page was already there, and this is what it said.
# How Claude Science works with your data > Claude Science is a local-first application. Claude Science is a local-first application. Conversation history and artifacts are stored only on the member's device. Anthropic doesn't host a session store for the app and has nothing to browse, sync, or export. Prompts and completions sent to the model are processed by Anthropic and handled under Anthropic's standard retention and Trust & Safety policies. The following sections cover what Anthropic does receive. ## What Anthropic receives Each time the app calls Claude, the prompt and Claude's response travel to Anthropic's servers and are logged under Anthropic's standard retention policy for model traffic (see How long do you store my organization's data in the Privacy Center), the same policy that applies to other Claude products. If your organization has CMEK enabled, model-call logging follows the same CMEK handling as your other Claude products. Your organization's Custom Data Retention setting doesn't change that retention period; that setting governs conversation, project, and artifact data stored on Anthropic's servers, which this product doesn't create. The app also sends product-usage telemetry (event counts and timings, not conversation content), which can be turned off through device configuration. ## Remote compute When a member chooses to connect the app to remote compute (an owned server or cloud account they control), the app sends code and data directly to that destination. That traffic doesn't pass through Anthropic. Admins can't yet restrict whether members can connect to remote compute. For setup details, see [Remote compute clusters](/docs/claude-science/remote-compute-clusters) and [Compute providers](/docs/claude-science/compute-providers) in the user documentation. ## Connectors Directory connectors you publish as an admin are reached through Anthropic's hosted connector service, so your directory connector permissions and tunnels apply. Connectors a member adds locally (either running on their own computer or pointing at a custom URL) talk to their app directly, without routing through Anthropic. ## What this means for you as an admin Because conversations and artifacts live on members' computers, the Anthropic-side data controls (Custom Data Retention, Org Data Export, and the Compliance API) don't reach them. Device management is the control you have for that data: your device management software (such as your MDM or EDR) governs the app's local folder the same way it governs any other local application data. Identity controls (SSO, SCIM, roles) apply because sign-in goes through claude.ai; see [Admin controls](/docs/claude-science/admin-controls) for what IP allowlisting and session duration cover.
claude-science/legal-and-compliance First recorded · 36 lines, first recorded
# Legal and compliance ## Legal agreements ### License ## Usage policy ### Acceptable use ### Authentication and credential use ## Security and trust ### Trust and safety ### Security vulnerability reporting
The first capture of this source. The page was already there, and this is what it said.
# Legal and compliance > Legal agreements, compliance certifications, and security information for Claude Science. Legal agreements, compliance certifications, and security information for Claude Science. ## Legal agreements ### License Your use of Claude Science is subject to:\ [Commercial Terms](https://www.anthropic.com/legal/commercial-terms) - for Team and Enterprise users\ [Consumer Terms of Service](https://www.anthropic.com/legal/consumer-terms) - for Pro and Max users ## Usage policy ### Acceptable use Claude Science usage is subject to the [Anthropic Usage Policy](https://www.anthropic.com/legal/aup). Advertised usage limits for Pro and Max plans assume ordinary, individual usage of Claude Science. ### Authentication and credential use Claude Science authenticates with Anthropic's servers using OAuth tokens. OAuth authentication is intended exclusively for purchasers of Claude Pro, Max, Team, and Enterprise subscription plans and is designed to support ordinary use of Claude Science and other native Anthropic applications. More information about how users can authenticate with OAuth tokens can be found in [Logging in to your Claude account](https://support.claude.com/en/articles/13189465-logging-in-to-your-claude-account).\ Anthropic reserves the right to take measures to enforce these restrictions and may do so without prior notice.\ For questions about permitted authentication methods for your use case, please [contact sales](https://www.anthropic.com/contact-sales?utm_source=claude_science\&utm_medium=docs\&utm_content=legal_compliance_contact_sales). ## Security and trust ### Trust and safety You can find more information in the [Anthropic Trust Center](https://trust.anthropic.com) and [Transparency Hub](https://www.anthropic.com/transparency). ### Security vulnerability reporting Anthropic manages its security program through HackerOne. [Use this form to report vulnerabilities](https://hackerone.com/4f1f16ba-10d3-4d09-9ecc-c721aad90f24/embedded_submissions/new).\ © Anthropic PBC. All rights reserved. Use is subject to applicable Anthropic Terms of Service.
claude-science/literature-access First recorded · 30 lines, first recorded
# Literature access ## Available credentials
The first capture of this source. The page was already there, and this is what it said.
# Literature access > Claude retrieves open-access full text without credentials; add publisher keys or a library proxy to reach paywalled text you're entitled to. Claude retrieves open-access full text without credentials. To reach paywalled text you're entitled to, add publisher keys or your library's proxy in the Claude Science app: select the gear icon and choose **Settings**, then select **Credentials**, then choose **Literature access (journals, etc.)** in the **Services** list. No key bypasses a paywall. <Note> These panels live in the Claude Science app's own **Settings**, separate from your claude.ai account and organization settings. If you've added custom credentials, the **Services** list appears below your **Custom** credentials. </Note> Given a DOI or title, Claude tries in order: an open-access copy (Unpaywall, Semantic Scholar, PubMed Central), CrossRef full-text links, publisher routes you hold keys for, your library proxy, then the publisher page. Retrieved files (PDF, XML, or text) are saved into the session. ## Available credentials Each credential in the **Literature access (journals, etc.)** form is optional and independent. | Credential | Effect | | ---------------------------------------------- | ------------------------------------------------------------- | | **Elsevier API key** + institutional token | Enables the Elsevier route (subscription still required) | | **Springer Nature API key** | Enables the Springer Nature route | | **Semantic Scholar API key** | Speeds the Semantic Scholar step | | **NCBI API key** | Raises the PubMed rate limit from 3 to 10 requests per second | | **CORE API key** | Gives skills access to the CORE open-access aggregator | | Institutional **EZproxy URL** + session cookie | Retries publisher links through your library | OpenAlex has its own entry in the same **Services** list: add a free **OpenAlex API key** there (create one on the [OpenAlex API settings page](https://openalex.org/settings/api)). OpenAlex requires a key on every request, so OpenAlex-backed literature search needs one configured. NCBI, EBI, and OurResearch (Unpaywall) ask callers to provide a contact email. The first time this applies, a **Share a contact email with research data services?** card appears. Sharing an email enables the Unpaywall step. You can also set this in the app's **Settings**, on the **General** tab, under **Contact email**. Claude paces requests to each provider at one per second, backs off when asked, and identifies itself in every request. Paywalled HTML isn't scraped.
claude-science/manage-on-devices First recorded · 46 lines, first recorded
# Manage Claude Science on devices ## Where the app stores data ## Deploy configuration with device management ## Telemetry ## Endpoint detection and response ## Required updates
The first capture of this source. The page was already there, and this is what it said.
# Manage Claude Science on devices > Claude Science is a desktop application that stores all member content locally. Claude Science is a desktop application that stores all member content locally. This page covers what IT and endpoint teams need to know: where the app writes data, how to deploy configuration with device management, what telemetry is sent, and what members see when Anthropic requires an update. ## Where the app stores data The app writes to two locations on each member's computer: Configuration: \~/.claude-science/config.toml holds all app settings. Every key is optional; the app starts with no file present. This is the file to deploy through device management.\ Data: the app's data directory holds conversations, generated artifacts, delegation configurations, and workspace files in a per-organization subfolder (orgs/`<organization-id>`/), stored as a local database plus files. Authentication tokens and the shared package environment live under \~/.claude-science/ regardless of the data directory, so endpoint backup or wipe policies that target the data directory don't affect sign-in state. Your endpoint tooling governs these folders the same way it governs any other local application data. There's no Anthropic-hosted copy, so Custom Data Retention, Org Data Export, and the Compliance API don't reach them. ## Deploy configuration with device management To set configuration keys organization-wide, deploy \~/.claude-science/config.toml through your MDM or endpoint tool. Claude Science doesn't read a system-level managed-preferences file, so there's no native MDM configuration channel. Deploying the per-member config.toml is the supported approach. The keys most relevant to admins are: | Key | Effect | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | disable\_telemetry = true | Stops the app from sending product-usage telemetry to Anthropic. | | data\_dir = "`<path>`" | Moves conversations, artifacts, and workspaces to a managed location (for example, a volume your backup tooling covers). | | \[update] auto\_update = false | Prevents the app from updating itself; pair with your own distribution channel. | | \[sandbox.network] enabled = false | Blocks network access from the app's local code-execution sandbox. The similarly named \[sandbox] network\_isolated key does not control this. | The [configuration file reference](/docs/claude-science/configuration-file-reference) documents the network-related keys and their defaults, and [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks) covers the proxy, TLS-inspection, and mirror settings. ## Telemetry The app sends product-usage telemetry (event counts and timings, not conversation content) to Anthropic. There's no in-app setting for this; consent is covered by your organization's acceptance of Anthropic's commercial terms. To turn telemetry off on managed devices, use either of: Set disable\_telemetry = true in \~/.claude-science/config.toml (deployable through MDM).\ Set the DO\_NOT\_TRACK environment variable on the device. Both are device-level settings. There's no per-member or per-organization telemetry toggle in Organization settings. ## Endpoint detection and response Claude Science runs analysis code inside a local sandbox on the member's computer. On macOS, sandboxed analysis processes run as ordinary child processes and are visible to host-level EDR tools. On Linux, they run inside a separate PID namespace with an isolated process view, so host-level EDR won't see them as ordinary children of the app. ## Required updates Anthropic may set a minimum supported version of the app. When a member's installed version falls below that floor, the app shows a full-page notice that the installed version is no longer supported and blocks further use until the member updates. Admins don't configure this floor; it's set by Anthropic. If your organization distributes the app through its own channel with auto-update disabled, plan to push updates promptly when Anthropic raises the floor.
claude-science/monitor-usage First recorded · 27 lines, first recorded
# Monitor Claude Science usage ## Analytics ## Admin API
The first capture of this source. The page was already there, and this is what it said.
# Monitor Claude Science usage > Claude Science usage counts against each member's standard weekly quota and uses the same seat as the rest of claude.ai. Claude Science usage counts against each member's standard weekly quota and uses the same seat as the rest of claude.ai. You can track adoption in Analytics and through the Admin API. ## Analytics Open Analytics from the user menu and select the Claude Science tab to see adoption and session metrics for this product. To see spend, or to compare active members across products, select Claude Science in the product filter on the Overview tab. The Monitor usage link in Organization settings > Claude Science opens Analytics. ## Admin API The Claude Enterprise Admin API (Enterprise plans only) returns Claude Science usage alongside your other products. Per-member metrics (GET /v1/organizations/analytics/users, science\_metrics object): | Field | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------- | | distinct\_session\_count | Number of distinct Claude Science sessions. Null on aggregated rows where a distinct count can't be computed. | | message\_count | Number of messages sent in Claude Science sessions. | | delegation\_count | Number of delegations (handoffs to a specialized agent) in Claude Science sessions. | | remote\_compute\_job\_count | Number of remote compute jobs launched from Claude Science sessions. | | skills\_used\_count | Total number of skill invocations in Claude Science sessions. | See the Admin API reference for authentication and the full schema.
claude-science/network-requirements First recorded · 103 lines, first recorded
# Network requirements ## App connections ### Full-text and literature retrieval ## Analysis sandbox domains ### Package management domains ### Research database domains ### Optional compute integrations ### Domains the sandbox always blocks ## Domains the member's browser loads ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Network requirements > The domains Claude Science connects to, grouped for a proxy or firewall allowlist: the app's connections to Anthropic, the analysis sandbox's package and research domains, the domains a package mirror adds and removes, and the built-in list of domains it always blocks. 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](/docs/claude-science/corporate-networks). ## 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. | Domain | Required when | Purpose | | --------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `claude.ai` | Always | Browser-based sign-in, usage analytics, feature configuration, and the catalog of available connectors | | `platform.claude.com` | Always | Completing sign-in (the OAuth token exchange) | | `api.anthropic.com` | Always | The Claude API for every request Claude makes, plus account and usage information | | `*.mcp.claude.com` | When members use the Anthropic-hosted connectors | PubMed, ClinicalTrials.gov, ChEMBL, and bioRxiv connectors | | `storage.googleapis.com` | When automatic updates are on | Update manifests and installers | | `api.github.com`, `codeload.github.com` | When members import skills from a GitHub repository | Fetching the skill repository's contents | 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. | Domain | Required when | Purpose | | ------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------- | | `api.unpaywall.org` | When Claude retrieves full text | Locating open-access copies of articles | | `doi.org` | When Claude resolves a DOI | DOI resolution | | `eutils.ncbi.nlm.nih.gov`, `www.ncbi.nlm.nih.gov` | When Claude searches PubMed | PubMed/PMC article records and full-text files | | `api.semanticscholar.org`, `api.crossref.org` | When Claude searches the literature | Scholarly search and citation metadata | | `api.openalex.org` | When a member adds an OpenAlex API key | Validating the stored key | | `api.elsevier.com`, `api.springernature.com` | Only when the member has stored those publishers' API keys | Publisher full-text APIs | ## 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. | Domain | Purpose | | ----------------------------------------------------------------------------------------- | ----------------------------------------------- | | `pypi.org`, `*.pypi.org`, `files.pythonhosted.org` | Python packages from PyPI | | `conda.anaconda.org`, `repo.anaconda.com`, `anaconda.org`, `*.anaconda.org`, `*.conda.io` | conda packages | | `cran.r-project.org`, `cloud.r-project.org`, `bioconductor.org`, `www.bioconductor.org` | R packages from CRAN and Bioconductor | | `registry.npmjs.org` | npm packages for connectors that need them | | `github.com`, `*.github.com`, `*.githubusercontent.com` | Tools and packages published as GitHub releases | 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](/docs/claude-science/corporate-networks#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**. | Group | Domains | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NCBI and NIH | `*.ncbi.nlm.nih.gov`, `*.nih.gov`, `cactus.nci.nih.gov` | | Genomics and biology | `rest.ensembl.org`, `grch37.rest.ensembl.org`, `*.ensembl.org`, `reactome.org`, `*.reactome.org`, `rest.kegg.jp`, `*.kegg.jp`, `cellguide.cellxgene.cziscience.com`, `gnomad.broadinstitute.org`, `gtexportal.org`, `jaspar.elixir.no`, `www.encodeproject.org`, `mygene.info`, `rfam.org`, `www.cbioportal.org`, `sparql.rhea-db.org`, `bindingdb.org`, `www.bindingdb.org`, `r12.finngen.fi`, `pheweb.jp`, `api.genome.ucsc.edu`, `unibind.uio.no` | | Proteomics | `rest.uniprot.org`, `*.uniprot.org`, `string-db.org`, `*.string-db.org`, `*.ebi.ac.uk`, `search.foldseek.com`, `rcsb.org`, `*.rcsb.org`, `*.proteinatlas.org` | | Literature and citations | `api.semanticscholar.org`, `api.biorxiv.org`, `www.biorxiv.org`, `api.crossref.org`, `doi.org`, `api.openalex.org`, `arxiv.org`, `*.arxiv.org` | | Clinical and pharma | `api.fda.gov`, `clinicaltrials.gov`, `*.clinicaltrials.gov`, `api.clinpgx.org`, `api.platform.opentargets.org`, `cancer.sanger.ac.uk`, `actionability.clinicalgenome.org`, `search.clinicalgenome.org`, `erepo.genome.network`, `civicdb.org`, `api.grants.gov`, `www.antibodyregistry.org`, `cartblanche22.docking.org`, `files.docking.org` | ### Optional compute integrations These domains matter only when a member turns on the matching integration. | Domain | Required when | Purpose | | --------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `health.api.nvidia.com` | When members enable NVIDIA-hosted BioNeMo inference | NVIDIA's hosted inference endpoint; a member can enter a different endpoint host when connecting BioNeMo under **Settings** > **Compute** | | `nvcr.io` | When members run NVIDIA NIM containers locally | Pulling NVIDIA container images | | `api.modal.com`, `*.w.modal.host` | When members connect a Modal account for remote compute | Modal's API and its dynamic worker hosts, reached from the member's machine | ### 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. | Domain | Purpose | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `claude.ai` | The sign-in authorization page | | `console.anthropic.com` | The sign-in fallback page, which shows a one-time code the member pastes into the app when the browser cannot return to the app's local callback address | | `cdn.jsdelivr.net`, `esm.sh`, `unpkg.com`, `cdnjs.cloudflare.com` | JavaScript display libraries for interactive previews | | `3dmol.org`, `3dmol.csb.pitt.edu` | Molecular structure viewer | | `*.claudemcpcontent.com` | Isolated frames that display Claude's HTML previews and interactive connector output. A standard desktop install serves these frames from the app's own local address, so this entry matters mainly where members open Claude Science from a non-local address | ## Related resources * [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks): proxy, TLS-inspection, and package-mirror settings * [Configuration file reference](/docs/claude-science/configuration-file-reference): the network keys in the configuration file * [Manage Claude Science on devices](/docs/claude-science/manage-on-devices): deploying the configuration file with device management
claude-science/overview First recorded · 20 lines, first recorded
# Claude Science ## Requirements
The first capture of this source. The page was already there, and this is what it said.
# Claude Science > Anthropic's AI workbench for rigorous science. Claude Science is a desktop application that pairs Claude with an analysis environment on your computer. Available in beta on macOS and Linux. You describe a research task or analysis in plain language; Claude writes and runs Python, R, or shell code in a sandbox, reads the folders you grant it, pulls data from scientific databases through connectors, and saves results as versioned artifacts with a full provenance record. A background reviewer can check Claude's claims against the work that was actually run. Your files stay on your computer, and code runs in a sandbox. You approve each new folder, network host, and remote job before Claude can use it. <Note> Claude can make mistakes. The reviewer reduces, but doesn't eliminate, errors. It checks claims against the execution record and doesn't re-run analyses. Verify results before relying on them in research, publication, or downstream decisions. Claude Science is a research tool and isn't intended for clinical or diagnostic use. </Note> ## Requirements * A Claude account on a Pro, Max, Team, or Enterprise plan. On Team and Enterprise plans, an Owner must [enable Claude Science for the organization](/docs/claude-science/enable-claude-science) first. * macOS 13 or later (Apple silicon or Intel), or Linux x64 on a glibc-based distribution. * About 5 GB of free disk space for the runtime and starter environments. * On Linux: socat, bubblewrap 0.8.0 or later, and unprivileged user namespaces permitted by the kernel.
claude-science/remote-compute-clusters First recorded · 33 lines, first recorded
# Remote compute clusters ## Adding a host ## Running jobs ## Host details
The first capture of this source. The page was already there, and this is what it said.
# Remote compute clusters > Connect a machine you can reach over SSH (a lab workstation or an HPC login node) so Claude can run jobs on it. Connect a machine you can reach over SSH (a lab workstation or an HPC login node) so Claude can run jobs on it. Use it to connect to a remote workstation with a GPU, or your existing HPC cluster. Claude Science uses your existing `~/.ssh/config`, authenticates with your key or `ssh-agent`, and installs nothing on the host itself. ## Adding a host Go to **Settings > Compute** > **SSH hosts** > **Add SSH host**.\ Choose or type an alias from your `~/.ssh/config`. The address, user, port, and any `ProxyJump` come from that file.\ Optionally add notes about the host (partition, account code, module loads, whether software can be installed). Claude reads these before the first job.\ Optionally override **User**, **Port**, or **Identity file** under **Advanced**.\ Click **Add**. Adding a host runs a read-only probe that records CPUs, memory, GPUs, CUDA driver, presence of conda/modules/Apptainer, scratch directories, and whether `sbatch` exists. On SLURM clusters it reads partitions. Results are saved as editable notes on the host's detail page; re-run with **Probe**. ## Running jobs Workstations run jobs as detached processes. SLURM clusters receive jobs via `sbatch`. Jobs survive connection loss. On the host's detail page, set **Scratch directory** (must be on a shared filesystem for SLURM) and **Concurrent job limit** (default 100). When Claude proposes a remote job, a **Run this job on `<host>`?** card shows the command and script. Approve with **Once**, **This conversation**, **This project**, or **Global** scope. On approval, the job script and inputs are copied to a job directory under the scratch directory. <Warning> Remote jobs run outside the sandbox, as your user on the host, with access to everything your account can read and write there. </Warning> Default job timeout is 30 minutes; tell Claude before submitting longer work. When a job finishes, outputs are pulled back into the session. Files over the size threshold (about 100 MB by default) stay on the host, and Claude records their paths. ## Host details Claude reads host-specific instructions from the Details document on the host's detail page. It holds notes that describe the host's setup and how to run jobs on it: how environments are activated, where data and packages live, and the cluster's scheduling conventions. Claude updates these as it works with the host, and you can edit them at any time.
claude-science/run-on-remote-linux-server First recorded · 83 lines, first recorded
# Run on a remote Linux server ## Install dependencies ## Install Claude Science ## Forward the ports from your computer ## Start Claude Science ## Sign in ## Keep it up to date ## Troubleshooting
The first capture of this source. The page was already there, and this is what it said.
# Run on a remote Linux server
> Install Claude Science on a cloud VM or lab server and use it from your own browser through an SSH tunnel.
Claude Science runs on a remote Linux server (a cloud VM or a lab machine) the same way it runs on a workstation: the application and your data stay on the server, and you use the web app from your computer's browser through an SSH tunnel. Setup takes about five minutes, plus a few minutes of environment setup on first launch.
<Note>
This page covers running all of Claude Science on a remote machine. To keep Claude Science on your own computer and have it run jobs on a machine you reach over SSH, see [Remote compute clusters](/docs/claude-science/remote-compute-clusters).
</Note>
The server needs x64 Linux on a glibc-based distribution (arm64 and musl-based distributions such as Alpine aren't supported), about 5 GB of free disk space, and the system packages below. Your Claude account needs a Pro, Max, Team, or Enterprise plan; see [Requirements](/docs/claude-science/overview#requirements).
## Install dependencies
Claude runs code inside a sandbox, and the sandbox needs two system packages: bubblewrap and socat. On Ubuntu or Debian:
```bash theme={null}
sudo apt-get update && sudo apt-get install -y curl bubblewrap socat
```
<Note>
The sandbox requires bubblewrap 0.8.0 or later; check with `bwrap --version`. Ubuntu 24.04 ships a new enough version, and Ubuntu 22.04 doesn't. The sandbox isn't optional: Claude Science refuses to start rather than run code unsandboxed.
</Note>
## Install Claude Science
```bash theme={null}
curl -fsSL https://claude.ai/install-claude-science.sh | bash
```
The installer downloads the current release, verifies its checksum, and installs the `claude-science` command in `~/.local/bin`. If it prints a PATH line at the end, add that line to your shell profile. Then confirm the command works:
```bash theme={null}
. ~/.profile
claude-science --version
```
## Forward the ports from your computer
Set up the tunnel before you start Claude Science: the sign-in link it prints is only valid for about three minutes.
By default, the web app listens only on the server's localhost, so it isn't exposed to the network. An SSH tunnel makes it reachable from your computer. Claude Science uses two ports: one for the web app (8000) and a separate one for previews of generated HTML, served from its own origin so a previewed page can't read your session. The preview port is always the web app port plus one, so 8001 by default. Forward both. In a terminal on your computer:
```bash theme={null}
ssh -L 8000:localhost:8000 -L 8001:localhost:8001 [email protected]
```
Leave that terminal open; the tunnel lasts as long as the SSH connection. If you work on the server through VS Code's Remote-SSH extension, it forwards ports automatically as the app uses them; check its Ports panel to confirm both ports are forwarded.
## Start Claude Science
On the server:
```bash theme={null}
claude-science serve --no-browser
```
First launch prints the sign-in link, of the form `http://localhost:8000/?nonce=...`, right away, and continues setting up its starter Python and R environments; the setup can take a few minutes and about 5 GB of disk. If port 8000 or 8001 is taken on either machine, pass a different port to serve (for example `--port 8765`; previews then use the next port up, 8766) and change the `ssh -L` forwards to match.
To run it in the background instead, use `claude-science serve --no-browser --detached`. `claude-science status` reports whether it's running, and `claude-science stop` stops it.
## Sign in
Open the printed link in your computer's browser. The link is single-use and expires about three minutes after it's printed; run `claude-science url` on the server to print a fresh one at any time. Restarting with `claude-science stop` then `claude-science serve --no-browser` also prints a fresh link.
Sign in with your Claude account. If the sign-in redirect can't find its way back through the tunnel, choose **Paste a code** on the sign-in screen. Then complete the setup wizard as described in [Get started](/docs/claude-science/get-started).
## Keep it up to date
`claude-science update` checks for and installs updates. See [Command line settings](/docs/claude-science/command-line-settings) for the full command reference, including `logs` and the `serve` flags.
## Troubleshooting
| Symptom | What it means |
| ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `command not found: claude-science` | `~/.local/bin` isn't on your PATH yet. Run `. ~/.profile` or open a new terminal. |
| An error mentioning `bwrap too old` | The server's bubblewrap is older than 0.8.0. Upgrade it, or use a distribution that ships a newer version, such as Ubuntu 24.04 or later. |
| An error mentioning `cannot create unprivileged user namespaces` | The kernel or an AppArmor profile blocks the sandbox from creating user namespaces; some Ubuntu 24.04 images restrict this. The error message names the exact setting to change for your distribution. |
| The sign-in link shows an expired-link page | Links are single-use and valid for about three minutes. Run `claude-science url` on the server and open the fresh link; restarting with `claude-science stop` then `claude-science serve --no-browser` also prints one. |
| Sign-in stops at claude.ai | The redirect couldn't return through the tunnel (choose **Paste a code**), your account is on the Free plan (an upgrade is required), or your Team or Enterprise organization hasn't [enabled Claude Science](/docs/claude-science/enable-claude-science) yet. |
| Interactive HTML previews render as static snapshots after a short delay (charts don't respond) | The tunnel isn't forwarding the preview port. Add the second `-L` forward; the preview port is the web app port plus one (8001 by default). |
| The browser can't reach `localhost:8000` | The tunnel isn't up; rerun the `ssh -L` command. If the tunnel is up, confirm Claude Science is running on the server with `claude-science status`. |
| The installer reports no binary for your platform | Claude Science on Linux needs x64 with glibc. arm64 servers and musl-based distributions such as Alpine aren't supported. |
claude-science/run-on-windows-wsl First recorded · 90 lines, first recorded
# Run on Windows with WSL ## Enable WSL ## Install dependencies ## Install Claude Science ## Run it ## First launch ## Keep it running ## Troubleshooting
The first capture of this source. The page was already there, and this is what it said.
# Run on Windows with WSL
> Claude Science doesn't ship a native Windows build yet, but the Linux binary runs well under Windows Subsystem for Linux (WSL 2).
Claude Science doesn't ship a native Windows build yet, but the Linux binary runs well under Windows Subsystem for Linux (WSL 2). Setup takes about five minutes.
## Enable WSL
In PowerShell, run as Administrator:
```powershell theme={null}
wsl --install -d Ubuntu-24.04
```
Reboot if Windows prompts you to, then open **Ubuntu 24.04** from the Start Menu and create your Linux user when asked.
<Note>
Use Ubuntu 24.04 or newer. Claude Science's sandbox requires bubblewrap 0.8.0 or later, and Ubuntu 22.04 ships an older version. WSL 2 is also required (WSL 1 can't run the sandbox); `wsl --install` sets up WSL 2 by default. If you have an older WSL setup, check with `wsl -l -v` and upgrade with `wsl --set-version Ubuntu-24.04 2`.
</Note>
## Install dependencies
Inside the Ubuntu terminal:
```bash theme={null}
sudo apt update && sudo apt install -y curl bubblewrap socat
```
## Install Claude Science
Run the installer inside Ubuntu. It downloads the current release, verifies its checksum, and installs the `claude-science` command:
```bash theme={null}
curl -fsSL https://claude.ai/install-claude-science.sh | bash
```
Then confirm the command is on your PATH:
```bash theme={null}
. ~/.profile
claude-science --version
```
<Note>
Install from inside Ubuntu rather than downloading the binary with a Windows browser and copying it across. The installer verifies the download and keeps you on the stable release channel.
</Note>
## Run it
```bash theme={null}
claude-science serve --port 8765 --no-browser
```
First launch prints progress to the terminal and ends with a local URL. Copy that URL into any Windows browser: WSL 2 forwards `localhost` automatically, so the link works from Windows as-is. The URL contains a one-time sign-in token; to print a fresh one later, run:
```bash theme={null}
claude-science url
```
Then sign in with your Claude account and complete the setup wizard as described in [Get started](/docs/claude-science/get-started).
## First launch
On first launch, Claude Science sets up its starter Python and R environments and the bundled connectors for scientific databases and tools. On a fresh install this takes several minutes, and longer on a slow connection. While setup runs, some connectors can show a load error; most clear on their own once setup finishes. If a connector's error says its automatic retries are paused, turn the connector off and on again in **Settings** > **Connectors**, or restart Claude Science (`claude-science stop`, then the `serve` command above), to retry it.
## Keep it running
The app runs inside the WSL virtual machine, so it stops when WSL shuts down. Closing your last Ubuntu terminal shuts the VM down after a short idle period, and `wsl --shutdown` stops it immediately.
To start Claude Science again from PowerShell without opening an Ubuntu terminal:
```powershell theme={null}
wsl -d Ubuntu-24.04 -- ~/.local/bin/claude-science serve --port 8765 --no-browser
```
Leave that PowerShell window open; it keeps the VM alive. To run it in the background of an existing Ubuntu session instead:
```bash theme={null}
claude-science serve --port 8765 --no-browser --detached
```
## Troubleshooting
| Symptom | What it means |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `command not found: claude-science` | `~/.local/bin` isn't on your PATH yet. Run `. ~/.profile` or open a new terminal. |
| An error mentioning `bwrap too old` | Your Ubuntu version ships an older bubblewrap. Use Ubuntu 24.04 or newer. |
| `daemon already running on port 8765` | Claude Science is already running. Run `claude-science url` and open the printed link; there's no need to start it again. |
| `port 8765 is already in use` | A different program holds that port. Pick another with `--port 8080`. |
| The browser can't reach `localhost:8765` | Confirm the daemon is still running in WSL. If you use a custom `.wslconfig` network mode, try the WSL address (run `hostname -I` inside Ubuntu) instead of `localhost`. |