One read of Claude Documentationclaude-docs-20261016T173706Z
5 pages moved out of 277 read.
Pages moved
5
significant first
Pages read
277
in this capture
Captured
17:37 UTC
Corpus hash
ea0355bb8872
corpus-hash
What this read moved
1-5 of 5claude-science/tools-and-environments Changed · +38 / -3 lines
### Environments in granted folders ### How Claude Science detects a GPU
from line 31
3131
3232The sandbox has no root access or system package manager. `apt` and `sudo` aren't available; Claude uses conda-forge or builds from source instead.
3333
34### Environments in granted folders
35
36On Linux, a uv, conda, mamba, or pixi environment in a folder you've granted **Read & write** can still be read-only to Claude. This happens when the environment's package files are hard links shared with the tool's package cache, the folder where the tool keeps the packages it has downloaded. A change to those files could also change the cache and other environments that share them.
37
38Claude can still run code from the environment but can't add, update, or remove packages in it. The failure shows as `Read-only file system` from pip, uv, and pixi, and as `EnvironmentNotWritableError` from conda. In a uv project, `uv run` and `uv sync` fail the same way whenever they have to update the environment, for example after `pyproject.toml` changes.
39
40To add packages, choose one of these:
41
42* **In a uv project, ask Claude to use a separate environment.** Have Claude set `UV_PROJECT_ENVIRONMENT` to the full path of a folder in the session's [workspace folder](/docs/claude-science/core-concepts#projects-and-sessions) and run uv as usual. The variable has to stay set for later uv commands, including `uv run` and `uv sync`. The separate environment belongs to that session, so another session starts without it. For a change every session keeps, change the environment yourself in a terminal outside Claude Science.
43* **With any of these tools, change the environment yourself.** In a terminal outside Claude Science, use the tool's own commands to add, update, or remove packages.
44
3445## GPUs
3546
36If your Linux machine has GPUs, the sandbox makes them available to code Claude runs, including on multi-GPU machines. You first need to turn GPU access on in the Settings > Compute pane.
47If your Linux machine has NVIDIA GPUs, the sandbox makes them available to code Claude runs, including on multi-GPU machines. To use them, turn on the **Host GPU** switch in **Settings > Compute**. Sessions you start after that can use the GPU. A session started while the switch was off keeps running without it, and so does a session continued from it with **Continue as a new session**.
3748
3849<Note>
39 Allowing GPU access reduces the default sandboxing configuration applied by Claude Science.
50 Turning on the **Host GPU** switch reduces the default sandboxing configuration applied by Claude Science.
4051</Note>
4152
42If your machine has no GPU, Claude notes this when a task needs one and can run the work on the remote compute you've connected. See Remote compute clusters and External compute providers.
53If Claude Science finds no GPU, Claude notes this when a task needs one and can run the work on the remote compute you've connected. See [Remote compute clusters](/docs/claude-science/remote-compute-clusters) and [Compute providers](/docs/claude-science/compute-providers). If your machine has an NVIDIA GPU but the **Host GPU** switch isn't in **Settings > Compute**, or Claude says there's no GPU in a session started with the switch on, see [How Claude Science detects a GPU](#how-claude-science-detects-a-gpu).
54
55### How Claude Science detects a GPU
56
57On Linux, Claude Science detects an NVIDIA GPU by running `nvidia-smi`. When it finds no GPU this way, Claude treats the machine as having no GPU, and the **Host GPU** switch doesn't appear in **Settings > Compute** unless it's already on.
58
59Claude Science runs the first `nvidia-smi` it finds in these folders, in this order:
60
611. `/usr/local/nvidia/bin`
622. `/usr/bin`
633. `/bin`
644. `/usr/lib/wsl/lib`
655. `/opt/bin`
66
67To see which folder yours is in, run `command -v nvidia-smi` in a terminal outside Claude Science. Claude Science doesn't look for `nvidia-smi` in any other folder, such as `/usr/local/bin`. If the `nvidia-smi` in a listed folder is a link, the file it finally leads to, after any other links, must also be named `nvidia-smi` and be under `/usr`, `/lib`, `/lib64`, `/bin`, `/sbin`, or `/opt`. To see the file a link finally leads to, run `readlink -f` with its path, for example `readlink -f /usr/bin/nvidia-smi`.
68
69`nvidia-smi` also has to work without the `LD_LIBRARY_PATH` environment variable, because Claude Science doesn't pass that variable on to it, even when your terminal has it set. To check, run it in a terminal outside Claude Science by its full path with the variable removed, for example `env -u LD_LIBRARY_PATH /usr/bin/nvidia-smi`. If that fails where plain `nvidia-smi` works, the variable is the reason. Make `nvidia-smi` work without the variable, or ask your system administrator to.
70
71If `nvidia-smi` is in another folder, link it into `/usr/bin`, which takes administrator (`sudo`) access. If you don't have that access, ask your system administrator to make the link. For example, when `nvidia-smi` is in `/usr/local/bin`, run this in a terminal outside Claude Science:
72
73```bash theme={null}
74sudo ln -s /usr/local/bin/nvidia-smi /usr/bin/nvidia-smi
75```
76
77After either fix is in place, run `claude-science stop` in a terminal outside Claude Science and start Claude Science again. If Claude Science then finds the GPU, the **Host GPU** switch is in **Settings > Compute** and its label shows the GPU's name. Turn it on if it's off, then start a new session, not one made with **Continue as a new session**.
4378
third-party/claude-desktop/ssh-remote-sessions Changed · +82 / -6 lines
### Alert the user with hooks on the host
from line 15
15153. **Run.** The remote server starts the engine on the host with the inference credential and policy from your managed configuration. Every file read, edit, shell command, and git operation runs on the host, in the working directory the user chose there. Claude Desktop connects to [managed MCP servers](/docs/third-party/claude-desktop/extensions#managed-mcp-servers-admin) from the device and exposes them to the engine as tools.
16164. **Stream.** Claude's responses and tool output stream back to Claude Desktop. Permission prompts appear in Claude Desktop, and the engine waits on the host until the user answers.
1717
18The engine keeps running on the host through a dropped SSH link, device sleep, or the user quitting Claude Desktop. It finishes the current turn, or stops at a permission prompt, then idles until the user reopens the session. Reopening starts a fresh engine from the transcript stored on the host, so a turn that finished while the app was closed is shown in full; a turn still running at that moment is cut short and not continued automatically. While Claude Desktop is closed, no new turns run and the inference credential is not refreshed, so a turn that outlives the credential fails with an authentication error.
18The engine keeps running on the host through a dropped SSH link, device sleep, or the user quitting Claude Desktop. It finishes the current turn, or stops at a permission prompt, then idles until the user reopens the session. While Claude Desktop is closed, no new turns run and the inference credential is not refreshed, so a turn that outlives the credential fails with an authentication error. A restart of the app for an update counts as a quit.
1919
20When the user reopens the session after a quit, Claude Desktop rejoins the engine or replaces it, unless it refuses to start the session:
21
22* **Rejoins**: on a macOS or Linux device, Claude Desktop 2.42304.0 or later tries to rejoin an engine that 2.42304.0 or later started. If it rejoins, a turn still running goes on. It can fail to rejoin, for example after some Claude Desktop updates or after a change to the managed configuration since the engine started. After a quit it never rejoins on a Windows device, and never rejoins an engine that an earlier version started.
23* **Replaces**: otherwise, Claude Desktop ends the engine and starts a fresh one from the transcript stored on the host. A turn that finished while the app was closed is shown in full, and a turn that still runs is cut short. If the turn stays stopped, the user sends a message to continue it.
24
2025On a host that ends a user's processes at logout, the remote server and the engine end with the SSH connection that started them, so a turn in progress doesn't survive a disconnect. Linux hosts where systemd-logind's `KillUserProcesses` setting is `yes` and applies to the SSH user behave this way. To keep remote sessions running through a disconnect on such a host, ask the host's administrator to exempt the SSH user, for example by listing the user under `KillExcludeUsers` in the systemd-logind configuration.
2126
2227An idle engine stays on the host, with the credential in its environment, until one of these happens:
2328
24* The user reopens, archives, or deletes the session.
29* The user archives or deletes the session.
30* The user reopens the session and Claude Desktop ends the engine to start a fresh one.
2531* The host restarts.
26* A Claude Desktop update replaces the remote server on the host (deferred while a session on that host was active in the last 24 hours, for up to 7 days).
32* After an update that includes a new remote server, Claude Desktop replaces the host's remote server at a later connection. This ends the engines under the old server. Claude Desktop can put the replacement off while it believes that work is running on that host.
2733* On a Linux or macOS host, 30 days pass without a connection from Claude Desktop to the remote server. The remote server then stops and ends its engines. Requires Claude Desktop 1.52386.0 or later.
2834
2935While Claude Desktop is disconnected, the remote server keeps the most recent output of each running engine in a 16 MiB buffer. It drops older output, and the engine keeps running.
from line 36
3036
3137On a Linux or macOS host, if Claude Desktop stayed open, it rejoins the running engine when it reconnects after device sleep or a dropped SSH link. It catches up from the buffer, and loads the part of the conversation that the buffer has dropped from the transcript stored on the host. If it can't load all of it, the session shows "Some output produced while you were disconnected may be missing here."
3238
39Some tool calls wait for an answer from Claude Desktop, and fail while it is disconnected:
40
41* **File tools under a folder restriction**: if you set [`allowedWorkspaceFolders`](/docs/third-party/claude-desktop/configuration#allowedworkspacefolders), Claude Desktop checks each file read, search, and edit before it happens. While Claude Desktop is disconnected, each of these calls waits up to 10 minutes and then fails.
42* **Tools that your policy sets to ask**: if [`builtinToolPolicy`](/docs/third-party/claude-desktop/configuration#builtintoolpolicy) sets a bare tool name, such as `Bash`, to `ask`, Claude Desktop is consulted before each call to that tool. While Claude Desktop is disconnected, each call waits up to 10 minutes and then fails.
43* **Tools from MCP servers that run on the device**: these include your managed MCP servers (see [Where MCP servers run in a remote session](#where-mcp-servers-run-in-a-remote-session)). While Claude Desktop is disconnected, each call to one of their tools fails after about 30 seconds. The 30-second limit requires Claude Desktop 2.2553.0 or later.
44
45For a task that uses these tools, have the user keep the device awake and connected. For other limits, see [Limits while Desktop is disconnected](https://code.claude.com/docs/en/desktop#limits-while-desktop-is-disconnected).
46
47### Alert the user with hooks on the host
48
49A [hook](https://code.claude.com/docs/en/hooks) is a command of yours that the engine runs on the host at a set point in a session. With hooks, the host can tell the user that a turn is waiting at a permission prompt, has finished, or has failed with an API error, including while Claude Desktop is disconnected. To set them up, add this `hooks` key to `~/.claude/settings.json` in the SSH user's home directory on the host before the user starts the session.
50
51```json ~/.claude/settings.json theme={null}
52{
53 "hooks": {
54 "Notification": [
55 {
56 "matcher": "permission_prompt",
57 "hooks": [{ "type": "command", "command": "/path/to/alert-user.sh" }]
58 }
59 ],
60 "Stop": [
61 { "hooks": [{ "type": "command", "command": "/path/to/alert-user.sh" }] }
62 ],
63 "StopFailure": [
64 { "hooks": [{ "type": "command", "command": "/path/to/alert-user.sh" }] }
65 ]
66 }
67}
68```
69
70Replace `/path/to/alert-user.sh` with a script that you write and place on the host, for example one that posts to a messaging service that the host can reach. The engine runs the script as the SSH user and passes it the event as JSON on standard input, with fields such as `hook_event_name`, `session_id`, and `cwd`. The `Stop` event also carries Claude's last message, so forward only the fields that the alert needs.
71
72Have the script print nothing and exit with code 0, because a `Stop` hook's output and exit code can keep the turn going (see [Stop decision control](https://code.claude.com/docs/en/hooks#stop-decision-control)). To confirm the setup, have the user start a remote session on the host and send a message. The script runs when Claude finishes responding.
73
74The hooks run in these cases:
75
76* **A permission prompt waits for the user's answer**: the [`Notification`](https://code.claude.com/docs/en/hooks#notification) hook runs once the prompt has waited about six seconds
77* **Claude finishes responding**: the [`Stop`](https://code.claude.com/docs/en/hooks#stop) hook runs
78* **An API error, such as an authentication error, ends the turn**: the [`StopFailure`](https://code.claude.com/docs/en/hooks#stopfailure) hook runs in place of `Stop`
79
80The `Notification` hook doesn't run for a tool call that is waiting for Claude Desktop's own check. That check comes before any permission prompt for the call. Calls that wait for that check include these:
81
82* Each file read, search, and edit, if you set [`allowedWorkspaceFolders`](/docs/third-party/claude-desktop/configuration#allowedworkspacefolders)
83* Each call to a tool that [`builtinToolPolicy`](/docs/third-party/claude-desktop/configuration#builtintoolpolicy) sets to `ask` by its bare name, such as `Bash`
84* Each call to a tool from an MCP server that runs on the device
85
86While Claude Desktop is disconnected, each of these calls waits and then fails, after up to 10 minutes for file tools and tools set to `ask` (for each limit, see [How a remote session works](#how-a-remote-session-works)). Claude receives the failure as the call's result, and a further call of the same kind waits again, which delays the `Stop` hook. For a task that makes these calls, have the user keep the device awake and connected.
87
88To cover every user of a host, put the hooks in [Claude Code managed settings](https://code.claude.com/docs/en/settings#settings-files) on the host instead, which on a Linux host is the file `/etc/claude-code/managed-settings.json`. If the host already has Claude Code managed settings, add the hooks to those and leave [`parentSettingsBehavior`](https://code.claude.com/docs/en/settings-reference#parentsettingsbehavior) as it is, set or unset. Changing it changes how those settings combine with the policy that Claude Desktop supplies. If the host has none yet, also set `parentSettingsBehavior` to `"merge"` in the managed settings that you create.
89
90<Warning>
91 By default, Claude Code managed settings on the host replace the policy that Claude Desktop supplies, even if they hold only hooks (see [Managed configuration on the remote host](#managed-configuration-on-the-remote-host)). With `parentSettingsBehavior` set to `"merge"`, the policy that Claude Desktop supplies still applies, layered under the host's own policy.
92</Warning>
93
3394### Where MCP servers run in a remote session
3495
3596An MCP server in a remote session runs on the device or on the host, depending on how it was added.
from line 148
87148
88149On devices where users applied the configuration locally, deploy `sshHostAllowlist` in Claude Code's managed settings. That restricts SSH without an MDM profile taking ownership of the whole configuration (see [Update keys and managed precedence](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence)).
89150
151To turn off Code sessions that run on the device, so that users work in SSH remote sessions, set [`disableDesktopLocalSessions`](https://code.claude.com/docs/en/settings-reference#disabledesktoplocalsessions) to `true` in a [Claude Code managed-settings file](https://code.claude.com/docs/en/settings#settings-files) or OS policy on the device. Claude Desktop then refuses to start or resume a Code session that runs on the device. If the device already has Claude Code managed settings, add the key to those and leave `parentSettingsBehavior` as it is, set or unset. Changing it changes how those settings combine with the policy that Claude Desktop supplies. If the device has none yet, also set `parentSettingsBehavior` to `"merge"` in the managed settings that you create. Without `"merge"`, the new managed settings replace the policy that Claude Desktop supplies to Claude Code on the device (see [Interaction with Claude Code's own managed settings](/docs/third-party/claude-desktop/code#interaction-with-claude-code%E2%80%99s-own-managed-settings) on the Code page).
152
153Before you deploy `disableDesktopLocalSessions`, make sure that the `sshHostAllowlist` that applies on the device, by [the order of its sources](#interaction-with-claude-code-managed-settings-on-the-device), allows the hosts that users need. While SSH remote sessions are off, a device that has `disableDesktopLocalSessions` set can start neither a local Code session nor an SSH remote session.
154
90155### Devices that move to an admin console organization
91156
92157A device that gets its SSH keys from a managed profile, a registry policy, or the profile's bootstrap server moves to the configuration from the [Enterprise Admin Console](/docs/third-party/claude-desktop/admin-console) when its user signs in to an organization that uses the console and chooses that organization in the dialog that follows. The app then restarts. A device that used such an organization before its profile arrived, and whose user hasn't signed out of the app since, moves back at its first launch on Claude Desktop 2.37337.0 or later, with no new sign-in and without asking the user, even if the stored sign-in has expired. To prevent that, add `disableDeploymentModeChooser` to the profile before devices update. `forceLoginOrgUUID` prevents it only for organizations it leaves out. Before Claude Desktop 2.37337.0, a device with such a profile ignores the admin console.
from line 219
154219Where the rules apply, they cover the following:
155220
156221* **Claude's file tools**: they refuse to create or change a file under the path, even in bypass permissions mode. A writable entry listed inside a read-only one is read-only for them too.
157* **Shell commands that Claude runs**: Claude Code's sandbox keeps them from writing under the path on a host where it runs, which on Linux needs Claude Code's [sandbox dependencies](https://code.claude.com/docs/en/sandboxing). The sandbox doesn't cover commands listed in Claude Code's `sandbox.excludedCommands`, or a path that contains one of `* ? [ ] ( ) { } | +` or a double quote. It may not stop commands in a folder that is listed through a symbolic link, so list each read-only folder by its real path, and keep it outside writable entries. On a host where the sandbox doesn't run, shell commands can still change the folder. For how the app reports that, see [Sandbox status on the remote host](#sandbox-status-on-the-remote-host).
222* **Shell commands that Claude runs with its Bash tool**: Claude Code's sandbox keeps them from writing under the path on a host where it runs, which on Linux needs Claude Code's [sandbox dependencies](https://code.claude.com/docs/en/sandboxing). The sandbox doesn't cover commands listed in Claude Code's `sandbox.excludedCommands`, or a path that contains one of `* ? [ ] ( ) { } | +` or a double quote. It may not stop commands in a folder that is listed through a symbolic link, so list each read-only folder by its real path, and keep it outside writable entries. On a host where the sandbox doesn't run, shell commands can still change the folder. For how the app reports that, see [Sandbox status on the remote host](#sandbox-status-on-the-remote-host).
158223
159The rules don't bind the SSH user, or other programs that run under that account. MCP servers on the host, hooks from Claude Code's configuration on the host, and the session's terminal can change the folder, and Claude Desktop and Claude Code can create git worktrees inside it.
224The rules don't bind the SSH user, or other programs that run under that account. MCP servers on the host, hooks from Claude Code's configuration on the host, and the session's terminal (including commands that Claude runs there) can change the folder, and Claude Desktop and Claude Code can create git worktrees inside it.
160225
161226### Sandbox status on the remote host
162227
from line 238
173238| Your organization's sandbox policy isn't fully applied on `<host>`, so shell commands there may run outside it | `overridden` | Claude Code managed settings on the host replace your policy, even when they say nothing about the sandbox, or they turn the sandbox off or loosen it | Set `parentSettingsBehavior` to `"merge"` in the host's managed settings, and remove `sandbox` values there that conflict with your policy |
174239| No message | `unknown` | Claude Code gives no answer that Claude Desktop can read | In a session on that host, ask Claude to run the two commands under [Confirm commands run inside the sandbox](https://code.claude.com/docs/en/sandboxing#confirm-commands-run-inside-the-sandbox) |
175240
241To check one session, have the user open it, wait until Claude has finished replying, and enter `/status` in the message box. Where your policy includes the sandbox, the **Session info** card shows what Claude Desktop last learned in a **Sandbox** row. Requires Claude Desktop 2.31226.0 or later. Find the value's `reason` in the table of messages and reasons for the cause and the fix:
242
243* **On · Strict**: no reason. Claude Code reports the sandbox from your policy turned on and running.
244* **Off · can't start**: `cannot_start` or `unsupported`
245* **Off**: `overridden`, and Claude Code reports no sandbox running
246* **On · not fully applied**: `overridden`, and Claude Code reports a sandbox that Claude Desktop can't match to your policy
247* **Couldn't check**: `unknown`
248
249If the card has no **Sandbox** row, have the user send a message, and enter `/status` again after Claude's reply.
250
176251With [`otlpEndpoint`](/docs/third-party/claude-desktop/configuration#otlpendpoint) set, your collector receives a `desktop_ssh_sandbox_check_failed` event under the `service.name` value `claude-desktop`, unless [`otlpDesktopLogLevel`](/docs/third-party/claude-desktop/configuration#otlpdesktoploglevel) is `off`. A session can send the event more than once, for example when the reason changes or after Claude Desktop restarts, so count distinct `session_id` values rather than events. The event carries these attributes:
177252
178253* **`reason`**: `cannot_start`, `unsupported`, `overridden`, or `unknown`
from line 300
225300
226301* For hosts behind a bastion, configure a `ProxyJump` or `ProxyCommand`. `ProxyJump` works only when the device's OpenSSH client carries the connection (the default on macOS and Linux). The built-in client refuses it. For the card that the user sees, see [Ask your IT administrator to set sshTransport to system-openssh](#ask-your-it-administrator-to-set-sshtransport-to-system-openssh).
227302* With the device's OpenSSH client, OpenSSH's own host key checking applies. For a host whose key isn't on record yet, where the app can show a prompt, it shows the key's fingerprint, asks the user whether to trust it, and records a trusted key in the user's `known_hosts` file, unless the user's own SSH configuration accepts new keys without asking. The app can't show a prompt on every connection, for example when it reconnects in the background. Distribute the host keys or a host certificate authority to the devices, so that each host's key is on record before users connect. `@cert-authority` entries are honored. A key that differs from the one on record for the host is refused, whatever the entry's `StrictHostKeyChecking` says, unless another setting in the SSH configuration that applies to the host takes that check away, such as `NoHostAuthenticationForLocalhost yes` for a host on a loopback address.
303* With the device's OpenSSH client, you can keep the app from asking users to trust the key of a host that isn't on record yet. Distribute the host keys in the client's system-wide `known_hosts` file, such as `/etc/ssh/ssh_known_hosts`, or distribute a host certificate authority. Then set `StrictHostKeyChecking yes`, for example under `Host *`, in the client's system-wide configuration file, such as `/etc/ssh/ssh_config`, which also governs other uses of that client, such as `git` over SSH. Where the SSH configuration that applies to a host has `StrictHostKeyChecking yes`, Claude Desktop doesn't ask the user to trust such a key, and `ssh` refuses the host if it can't verify the key. A key that differs from the one on record is handled the same way with or without this setting. The setting doesn't bind the user. By OpenSSH's own rules, `ssh` reads the user's `~/.ssh/config` before the system-wide file and keeps the first value it finds for a setting, so a `StrictHostKeyChecking` line there applies in place of yours. `ssh` also accepts a key that the user adds to their own `known_hosts` file, but under `yes` a connection from a terminal doesn't record the key.
228304* With the built-in client, the host's key must already be in the device's `~/.ssh/known_hosts` as a plain entry. The app does not prompt to accept a new key and does not evaluate `@cert-authority` entries, so have users connect once from a terminal before adding the host in the app.
229305* With the built-in client, an identity file protected by a passphrase is skipped, not prompted for. Load it into the SSH agent, or use an unencrypted key. With the device's OpenSSH client, the app asks for the passphrase once the host's key is verified, and skips the key if the user cancels.
230306* With the built-in client, a host reached through a `ProxyCommand` gets the same host key check as a host reached directly. Before Claude Desktop 2.9939.0, the built-in client skipped host key verification for such a host.
claude-science/core-concepts Changed · +2 / -0 lines
from line 34
3434
3535All standing grants are listed in Settings > Permissions and can be revoked there.
3636
37On Linux, a uv, conda, mamba, or pixi environment in a folder you've granted **Read & write** can still be read-only to Claude. See [Environments in granted folders](/docs/claude-science/tools-and-environments#environments-in-granted-folders).
38
3739## Plans
3840
3941Claude 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.
claude-science/get-started Changed · +1 / -0 lines
from line 179
179179* A Claude Science message on Windows says the app was not installed because the file could not be confirmed: the copy you opened still runs but isn't installed. Download the installer again from [claude.com/product/claude-science](https://claude.com/product/claude-science) and open the new file. If the message persists, the PC could not verify the publisher's signature, so ask your IT team.
180180* The Windows app reports that it couldn't set up the app window engine: the first launch downloads that engine from `downloads.claude.ai`, and this usually means the app couldn't reach it. Check the internet connection, and on a corporate network ask IT to allow that domain (see [Network requirements](/docs/claude-science/network-requirements)).
181181* On Linux, the installer stops with `The download service may be unreachable, or not yet available in your region`: the installer couldn't get the latest version from `storage.googleapis.com`. Check the internet connection, and on a corporate network ask IT to allow that domain (see [Network requirements](/docs/claude-science/network-requirements#app-connections)). Claude Science is available where Anthropic offers claude.ai. See [Supported countries and regions](https://www.anthropic.com/supported-countries).
182* On Linux, the installer stops with `was NOT installed` and says the copy you already had `was left as it is`: Claude Science was already installed, so the installer first tried to check that the new version starts on this computer. The check didn't succeed, so nothing was replaced. The message and the lines under it say why and, where there is a fix, what to do. If they point to the [configuration file](/docs/claude-science/configuration-file-reference), `~/.claude-science/config.toml`, fix what they report in that file, then run the installer again from the Linux tab of [Install](#install). Otherwise, keep using the copy you already had.
182183* On Linux, the shell reports `command not found` for `claude-science`: `~/.local/bin` isn't on your PATH. Add the PATH line that the installer printed to your shell profile, then open a new terminal.
183184* On Linux, `claude-science serve` stops with a `Sandbox unavailable:` message that mentions `bwrap was found on PATH at`, `is not where Claude Science runs it from`, `(PATH is not searched)`, or `is deliberately not used`: version 0.1.61 prints these messages, because it needs bubblewrap and socat installed for the whole system. If you updated to it from inside the app, the "Update available" notice shows "restart aborted" instead of these messages. Version 0.1.62 withdraws that requirement. Run `claude-science update` in a terminal, then start Claude Science again.
184185* On Linux, `claude-science serve` stops with `Sandbox unavailable: bwrap not found on PATH`: bubblewrap isn't installed, or isn't on your PATH. Install bubblewrap and socat with the command for your distribution in the Linux tab of [Install](#install).
claude-science/run-on-remote-linux-server Changed · +1 / -0 lines
from line 111
111111| 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 for the preview port that `claude-science url` prints (8001 by default), with that number on both sides. |
112112| 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`. |
113113| 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. |
114| The installer stops with a message mentioning `was NOT installed` | Claude Science was already installed on the server, so the installer first tried to check that the new version starts there. The check didn't succeed, so nothing was replaced. The message and the lines under it say why and, where there is a fix, what to do. If they point to the [configuration file](/docs/claude-science/configuration-file-reference), `~/.claude-science/config.toml`, fix what they report in that file, then run the installer again as shown in [Install Claude Science](#install-claude-science). Otherwise, keep using the copy you already had. |
114115