Configure cloud environments

Configure cloud environments 문서는 Claude Code 공식 문서(cloud-environments)를 한국어로 정리한 가이드입니다. Configure cloud environments for Claude Code cloud sessions: network access levels, environment variables, setup scripts, and environment caching. 명령·설정 키·코드 예시는 공식 문서를 그대로 보존하며, 해석과 절차 안내는 한국어로 제공합니다. 최종 동작은 설치 버전과 공식 원문을 확인하세요.

핵심 요약

Configure cloud environments for Claude Code cloud sessions: network access levels, environment variables, setup scripts, and environment caching.

한국어 가이드 범위: cloud-environments 경로의 설정·명령·제약·예시를 학습용으로 재구성합니다.

문서 구성

공식 문서의 주요 섹션은 다음과 같습니다.

Configure cloud environments
The Default environment
Configure your environment
Set environment variables
Select an environment from the CLI
Archive an environment
Organization-shared environments
Network access
Access levels
Allow specific domains
GitHub proxy
Security proxy
What's available in cloud sessions
What carries over from your setup
Installed tools
Work with GitHub issues and pull requests
Link output back to the session
Run tests, start services, and add packages
Resource limits
Setup scripts
Script requirements
Environment caching
Setup scripts vs. SessionStart hooks
Install dependencies with a SessionStart hook
Default allowed domains
Related resources

상세 내용

Configure cloud environments

The Default environment

Onboarding sets up the Default environment for you, whether you connect through the web or a CLI flow such as /web-setup; if web onboarding shows an environment form instead of creating the environment, keep the form's defaults to get the same Default environment. Default carries no configuration of its own:

주요 항목:

Trusted network access: sessions reach package registries and other allowlisted domains, and nothing else through the session's network.
No other configuration: Default defines no environment variables or setup script, so sessions start with just the pre-installed tools.
On the web, the Desktop app, and the mobile app, sessions use the environment shown in the selector. An admin-set organization default fills the selection when you haven't picked one.
From the CLI, sessions use your /remote-env pick, or fall back to your first available cloud environment.

Configure your environment

Create, edit, and archive environments from the environment selector at claude.ai/code, which you reach after web onboarding. Environments you create are personal to your account; shared environments created by your admins appear in the same selector. See Installed tools for what's available without any configuration.

Set environment variables

Environment variables use .env format, one KEY=value pair per line. Plain values don't need quotes, and if you quote a value with a matching pair, the quotes don't become part of the value. Quote a value that spans multiple lines or contains a #: in an unquoted value, # starts a comment and the rest of the line is dropped.

Select an environment from the CLI

Run /remote-env in your terminal to choose the default environment for cloud sessions you create from the CLI, such as claude --cloud. The command opens a picker of your existing environments and saves your choice to the remote.defaultEnvironmentId key in your user settings, so it applies in every project on your machine until you change it, unless the same key is set at a higher-precedence settings layer, such as a repo's project settings.

Archive an environment

To archive an environment, open it for editing and select Archive. You can't delete an environment, only archive it.

주요 항목:

Sessions already running in the environment continue to work.
The environment disappears from the selector and from /remote-env, so you can't pick it for new sessions.
No new session can start in an archived environment, on any surface. If the environment was your saved CLI default, CLI cloud sessions fall back to your first available cloud environment. Anything configured with the environment explicitly, such as a routine, can't start new sessions in it; point it at another environment.

Organization-shared environments

Owners and admins on Team and Enterprise plans can create cloud environments that are shared with every member of the organization. Shared environments appear in each member's environment selector alongside their personal ones, so a team can standardize on one configuration instead of each member recreating it.

Network access

Each environment sets one network access level, which controls the outbound connections its sessions can make. The default level, Trusted, allows package registries and other allowlisted domains; Custom takes your own domain list.

Access levels

The Network access field in the environment dialog takes one of four levels:

Level	Outbound connections
None	No outbound network access through the session's network
Trusted	Allowlisted domains only: package registries, GitHub, cloud SDKs
Full	Any domain
Custom	Your own allowlist, optionally including the defaults

Allow specific domains

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

GitHub proxy

All GitHub operations go through a dedicated proxy that keeps your real GitHub credentials outside the session's VM, independent of the environment's access level:

주요 항목:

Git credentials: the git client inside the VM uses a scoped credential, which the proxy verifies and swaps for your actual GitHub token.
API requests: requests from the built-in GitHub tools, and from gh under the proxy-injected placeholder, go out with your real credentials substituted.
Push protection: git push works only against the session's current working branch; cloning, fetching, and PR operations work normally.
Repository scope: GitHub API and release-asset requests reach only repositories attached to the session, so a setup script that downloads release assets from an unattached repository gets a 403.

Security proxy

Cloud sessions run behind an HTTP/HTTPS network proxy for security and abuse prevention purposes. All outbound internet traffic passes through this proxy, which provides:

주요 항목:

Protection against malicious requests
Rate limiting and abuse prevention
Content filtering for enhanced security
A DNS-level audit trail of requested hostnames

What's available in cloud sessions

Each session gets a fresh virtual machine (VM) running Ubuntu 24.04, regardless of your own operating system, with your repository cloned and common toolchains pre-installed. This section covers those defaults, the built-in GitHub tools, how to run tests and services, and the resource limits each VM gets.

What carries over from your setup

Cloud sessions start from a fresh clone of your repository. Anything you commit to the repo is available. Anything you've installed or configured only on your own machine isn't available in the session. Your organization's policy arrives separately through server-managed settings.

	Available in cloud sessions	Why
Your repo's `CLAUDE.md`	Yes	Part of the clone
Your repo's `.claude/settings.json` hooks	Yes	Part of the clone
Your repo's `.mcp.json` MCP servers	Yes	Part of the clone
Your repo's `.claude/rules/`	Yes	Part of the clone
Your repo's `.claude/skills/`, `.claude/agents/`, `.claude/commands/`	Yes	Part of the clone
Plugins declared in `.claude/settings.json`	Yes	Installed at session start from the marketplace you declared. Requires network access to reach the marketplace source
Your organization's server-managed settings	Yes	Fetched from Anthropic's servers when the session starts. See Surface coverage for how `availableModels` is enforced in cloud sessions. Settings deployed to your device through MDM or managed settings files don't apply, because the session runs on an Anthropic-managed VM
Your user `~/.claude/CLAUDE.md`	No	Lives on your machine, not in the repo
Your user `~/.claude/skills/`, `~/.claude/agents/`, `~/.claude/commands/`	No	Live on your machine, not in the repo. Commit them to the repo's `.claude/` directory instead. Cloud sessions automatically load skills you enable on claude.ai
Plugins enabled only in your user settings	No	User-scoped `enabledPlugins` lives in `~/.claude/settings.json`. Declare them in the repo's `.claude/settings.json` instead
MCP servers you added with `claude mcp add` at the default local scope or the user scope	No	Those write to `~/.claude.json` on your machine, not the repo. Add the server with `claude mcp add --scope project`, which writes the repo's `.mcp.json`, and commit that file
Transport variables in your repo's `.claude/settings.json` `env` block, such as `NODE_EXTRA_CA_CERTS` and the mTLS client certificate variables	No	The hosting environment manages the session's API connection, so Claude Code ignores these keys and notes each ignored key in the session's debug log
Static API tokens and credentials	No	No dedicated secrets store exists yet. See below
Interactive auth like AWS SSO	No	Not supported. SSO requires browser-based login that can't run in a cloud session

Installed tools

Cloud sessions come with common language runtimes, build tools, and databases pre-installed. The table below summarizes what's included by category.

Category	Included
Python	Python 3.x with pip, poetry, uv, black, mypy, pytest, ruff
Node.js	20, 21, and 22 via nvm, with npm, yarn, pnpm, bun¹, eslint, prettier, chromedriver
Ruby	3.1, 3.2, 3.3 with gem, bundler, rbenv
PHP	8.4 with Composer
Java	OpenJDK 21 with Maven and Gradle
Go	latest stable with module support
Rust	rustc and cargo
C/C++	GCC, Clang, cmake, ninja, conan
Docker	docker, dockerd, docker compose
Databases	PostgreSQL 16, Redis 7.0
Utilities	git, jq, yq, ripgrep, tmux, vim, nano

Work with GitHub issues and pull requests

Cloud sessions include built-in GitHub tools that let Claude read issues, list pull requests, fetch diffs, and post comments without any setup. These tools authenticate through the GitHub proxy using whichever method you configured under GitHub authentication options, so your token never enters the container.

주요 항목:

If you set a token, it passes through to the container unchanged, so your scripts, and GitHub's gh CLI if you install it, use it directly.
If you set neither and the GitHub proxy is handling authentication for your session, both variables read as the placeholder string proxy-injected in the commands Claude runs, and the proxy substitutes your real credentials on outbound GitHub requests. gh works without a token of your own, but a script that reads GITHUB_TOKEN directly gets the placeholder, not a usable token.

Link output back to the session

Each cloud session has a transcript URL on claude.ai, and the session can read its own ID from the CLAUDE_CODE_REMOTE_SESSION_ID environment variable. Use this to put a traceable link in PR bodies, commit messages, Slack posts, or generated reports so a reviewer can open the run that produced them.

Run tests, start services, and add packages

You don't get a shell into the session VM. Claude runs every command for you, so phrase the tasks in this section as requests in your prompt.

Resource limits

Cloud sessions run with approximate resource ceilings that may change over time:

주요 항목:

4 vCPUs
16 GB of RAM
30 GB of disk

Setup scripts

A setup script is a Bash script that runs when a new cloud session starts, before Claude Code launches. Use setup scripts to install dependencies, configure tools, or fetch anything the session needs that isn't pre-installed.

Script requirements

A setup script has three constraints to write around:

주요 항목:

Exit zero: if the script exits non-zero, the session fails to start. Append || true to non-critical commands so an intermittent install failure doesn't block the session.
Finish within five minutes: keep the script's total runtime under roughly five minutes so the environment cache can build. Run independent installs in parallel with & and wait, and move any single download that won't fit into a SessionStart hook that launches it in the background.
Network access for installs: package installs need to reach registries. The default Trusted level covers common package registries including npm, PyPI, RubyGems, and crates.io; with None network access, installs fail.

Environment caching

The setup script runs the first time you start a session in an environment. After it completes, Anthropic snapshots the filesystem and reuses that snapshot as the starting point for later sessions. New sessions start with your dependencies, tools, and Docker images already on disk, and skip the setup script step. This keeps startup fast even when the script installs large toolchains or pulls container images.

Setup scripts vs. SessionStart hooks

Use a setup script to provision the VM itself: toolchains and CLI tools that aren't pre-installed. Use a SessionStart hook for project setup that should run everywhere, cloud and local, like npm install.

	Setup scripts	SessionStart hooks
Where you configure them	The environment dialog at claude.ai/code	A settings file such as your repo's `.claude/settings.json`; see What carries over from your setup for which files reach a cloud session
When they run	Before Claude Code launches, skipped when a cached environment exists	After Claude Code launches, on every session including resumed
Where they run	Cloud sessions only	Local and cloud sessions

Install dependencies with a SessionStart hook

To install dependencies only in cloud sessions, pair a SessionStart hook with a script that checks where it's running.

주요 항목:

No cloud-only scoping: hooks run in both local and cloud sessions. To skip local execution, check the CLAUDE_CODE_REMOTE environment variable as shown above.
Requires network access: install commands need to reach package registries. If your environment uses None network access, these hooks fail. The default allowlist under Trusted covers npm, PyPI, RubyGems, and crates.io.
Proxy compatibility: all outbound traffic passes through a security proxy. Some package managers don't work correctly with this proxy. Bun is a known example.
Adds startup latency: hooks run each time a session starts or resumes, unlike setup scripts which benefit from environment caching. Keep install scripts fast by checking whether dependencies are already present before reinstalling.

The `matcher` limits the hook to the `startup` and `resume` events, and `$CLAUDE_PROJECT_DIR` resolves to the repository root, so the hook finds the script regardless of the session's working directory.

Next, create the script at `scripts/install_pkgs.sh`. It exits immediately outside the cloud, then installs your dependencies:

Default allowed domains

With Trusted network access, sessions can reach the following domains by default. Domains marked with * indicate wildcard subdomain matching, so *.gcr.io allows any subdomain of gcr.io.

주요 항목:

api.anthropic.com
statsig.anthropic.com
docs.claude.com
platform.claude.com
code.claude.com
claude.ai
github.com
www.github.com
api.github.com
npm.pkg.github.com
raw.githubusercontent.com
pkg-npm.githubusercontent.com
objects.githubusercontent.com
release-assets.githubusercontent.com
codeload.github.com
avatars.githubusercontent.com
camo.githubusercontent.com
gist.github.com
gitlab.com
www.gitlab.com
registry.gitlab.com
bitbucket.org
www.bitbucket.org
api.bitbucket.org
registry-1.docker.io
auth.docker.io
index.docker.io
hub.docker.com
www.docker.com
production.cloudflare.docker.com

주요 항목:

Claude Code on the web: start, manage, and share cloud sessions
Web quickstart: connect GitHub and start your first cloud session
Claude Tag: sessions Claude starts from Slack run in the same environments
Routines: scheduled runs use the same environments and network access levels
Remote Control: run sessions on your own machine's network and files instead
SessionStart hooks: repo-committed setup that runs in local and cloud sessions
Server-managed settings: organization policy that reaches cloud sessions

실습 체크리스트

공식 문서와 로컬/SDK 버전을 대조합니다.
관련 CLI·SDK 옵션은 공식 페이지와 --help로 교차 확인합니다.
Agent SDK 예시는 TypeScript/Python 패키지 최신 API를 우선합니다.
권한·호스팅·보안 설정 변경 후 통합 테스트를 실행합니다.

자주 쓰는 명령·설정 예시

Each session copies the environment's values once, at startup, into ordinary environment variables that any command Claude runs can read. Because running sessions don't re-read the configuration, editing or adding variables affects sessions you start afterward; sessions already running keep the values they started with.

Anyone who uses the environment can read the values, and cloud environments have no dedicated secrets store, so don't add API keys or other credentials. If a session needs a credential anyway, see [What carries over from your setup](#what-carries-over-from-your-setup).

### Select an environment from the CLI

Run `/remote-env` in your terminal to choose the default environment for cloud sessions you create from the CLI, such as [`claude --cloud`](/docs/en/claude-code-on-the-web#from-terminal-to-web). The command opens a picker of your existing environments and saves your choice to the `remote.defaultEnvironmentId` key in your [user settings](/docs/en/settings#settings-files), so it applies in every project on your machine until you change it, unless the same key is set at a higher-precedence [settings layer](/docs/en/settings#settings-precedence), such as a repo's project settings.

`/remote-env` only sets the default: it doesn't start a session, and it can't add or edit environments. Manage them at [claude.ai/code](https://claude.ai/code).

### Archive an environment

To archive an environment, open it for editing and select **Archive**. You can't delete an environment, only archive it.

Archiving affects new sessions, not running ones:

* Sessions already running in the environment continue to work.
* The environment disappears from the selector and from `/remote-env`, so you can't pick it for new sessions.
* No new session can start in an archived environment, on any surface. If the environment was your saved [CLI default](#select-an-environment-from-the-cli), CLI cloud sessions fall back to your first available cloud environment. Anything configured with the environment explicitly, such as a [routine](/docs/en/routines#environments-and-network-access), can't start new sessions in it; point it at another environment.

### Organization-shared environments

Owners and admins on Team and Enterprise plans can create cloud environments that are shared with every member of the organization. Shared environments appear in each member's environment selector alongside their personal ones, so a team can standardize on one configuration instead of each member recreating it.

Create, edit, and archive shared environments from the **Cloud environments** page in [admin settings](https://claude.ai/admin-settings). Each shared environment has a name, a [network access level](#access-levels), [environment variables](#set-environment-variables) in `.env` format, and a [setup script](#setup-scripts). Owners and admins choose the organization's [default environment](#the-default-environment) separately, at [claude.ai/admin-settings/claude-code](https://claude.ai/admin-settings/claude-code).

Values in a shared environment reach every member's sessions in that environment. Like personal environments, shared environments have no dedicated secrets store, so don't include secrets.

Shared environments add to members' selectors rather than replacing them.

## Network access

Each environment sets one network access level, which controls the outbound connections its sessions can make. The default level, **Trusted**, allows package registries and other [allowlisted domains](#default-allowed-domains); **Custom** takes your own domain list.

To change an environment's network access, [open it for editing](#configure-your-environment) and use the **Network access** selector in the dialog. The cloud icon that opens the selector appears on the app surfaces listed under [The Default environment](#the-default-environment) and in the [routine editor](/docs/en/routines#environments-and-network-access); personal environments don't have a separate page in your claude.ai account settings.

  MCP connectors you enable on a session or routine work without adding their hosts to **Allowed domains**, because connector traffic travels through Anthropic's servers rather than the session's network. You configure connectors per session or per routine; remove any you don't need to limit which tools Claude can reach. This relies on the same Anthropic-bound channel noted under [Security and isolation](/docs/en/claude-code-on-the-web#security-and-isolation).

### Access levels

The **Network access** field in the [environment dialog](#configure-your-environment) takes one of four levels:

| Level       | Outbound connections                                                                         |
| :---------- | :------------------------------------------------------------------------------------------- |
| **None**    | No outbound network access through the session's network                                     |
| **Trusted** | [Allowlisted domains](#default-allowed-domains) only: package registries, GitHub, cloud SDKs |
| **Full**    | Any domain                                                                                   |
| **Custom**  | Your own allowlist, optionally including the defaults                                        |

GitHub operations use a [separate proxy](#github-proxy) that is independent of this setting, and Claude Code's connection to the Anthropic API still works at **None**, as noted under [Security and isolation](/docs/en/claude-code-on-the-web#security-and-isolation).

### Allow specific domains

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

Sessions in this environment can now reach `api.example.com`, any subdomain of `internal.example.com`, and `registry.example.com`, and no other domains through the session's network; [GitHub traffic](#github-proxy) and [MCP connector traffic](#network-access) don't go through this allowlist. A leading `*.` matches every subdomain. To keep the [Trusted domains](#default-allowed-domains) too, check **Also include default list of common package managers**; leave it unchecked to allow only what you list.

Each environment has its own allowed-domains list; there's no organization-level allowlist that admins can push to every member's environments. [Server-managed settings](/docs/en/server-managed-settings) still apply inside cloud sessions, but none of them adds domains to the environment's network allowlist.

### GitHub proxy

All GitHub operations go through a dedicated proxy that keeps your real GitHub credentials outside the session's VM, independent of the environment's [access level](#access-levels):

* **Git credentials**: the git client inside the VM uses a scoped credential, which the proxy verifies and swaps for your actual GitHub token.
* **API requests**: requests from the built-in GitHub tools, and from `gh` under the [`proxy-injected` placeholder](#work-with-github-issues-and-pull-requests), go out with your real credentials substituted.
* **Push protection**: `git push` works only against the session's current working branch; cloning, fetching, and PR operations work normally.
* **Repository scope**: GitHub API and release-asset requests reach only repositories attached to the session, so a setup script that downloads release assets from an unattached repository gets a 403.

Committed files from public repositories arrive through `raw.githubusercontent.com`, which the [security proxy](#security-proxy) handles instead. That domain is in the default [Trusted list](#default-allowed-domains), so those files stay reachable unless the environment's [access level](#access-levels) excludes it.

### Security proxy

Cloud sessions run behind an HTTP/HTTPS network proxy for security and abuse prevention purposes. All outbound internet traffic passes through this proxy, which provides:

* Protection against malicious requests
* Rate limiting and abuse prevention
* Content filtering for enhanced security
* A DNS-level audit trail of requested hostnames

## What's available in cloud sessions

Each session gets a fresh virtual machine (VM) running Ubuntu 24.04, regardless of your own operating system, with your repository cloned and common toolchains pre-installed. This section covers those defaults, the built-in GitHub tools, how to [run tests and services](#run-tests-start-services-and-add-packages), and the [resource limits](#resource-limits) each VM gets.

### What carries over from your setup

Cloud sessions start from a fresh clone of your repository. Anything you commit to the repo is available. Anything you've installed or configured only on your own machine isn't available in the session. Your organization's policy arrives separately through [server-managed settings](/docs/en/server-managed-settings).

|                                                                                                                                                                                           | Available in cloud sessions | Why                                                                                                                                                                                                                                                                                                                  |
| :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Your repo's `CLAUDE.md`                                                                                                                                                                   | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.claude/settings.json` hooks                                                                                                                                                 | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.mcp.json` MCP servers                                                                                                                                                       | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.claude/rules/`                                                                                                                                                              | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.claude/skills/`, `.claude/agents/`, `.claude/commands/`                                                                                                                     | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Plugins declared in `.claude/settings.json`                                                                                                                                               | Yes                         | Installed at session start from the [marketplace](/docs/en/plugin-marketplaces) you declared. Requires network access to reach the marketplace source                                                                                                                                                                     |
| Your organization's [server-managed settings](/docs/en/server-managed-settings)                                                                                                                | Yes                         | Fetched from Anthropic's servers when the session starts. See [Surface coverage](/docs/en/model-config#surface-coverage) for how `availableModels` is enforced in cloud sessions. Settings deployed to your device through MDM or managed settings files don't apply, because the session runs on an Anthropic-managed VM |
| Your user `~/.claude/CLAUDE.md`                                                                                                                                                           | No                          | Lives on your machine, not in the repo                                                                                                                                                                                                                                                                               |
| Your user `~/.claude/skills/`, `~/.claude/agents/`, `~/.claude/commands/`                                                                                                                 | No                          | Live on your machine, not in the repo. Commit them to the repo's `.claude/` directory instead. Cloud sessions automatically load skills you enable on claude.ai                                                                                                                                                      |
| Plugins enabled only in your user settings                                                                                                                                                | No                          | User-scoped `enabledPlugins` lives in `~/.claude/settings.json`. Declare them in the repo's `.claude/settings.json` instead                                                                                                                                                                                          |
| MCP servers you added with `claude mcp add` at the default local scope or the user scope                                                                                                  | No                          | Those write to `~/.claude.json` on your machine, not the repo. Add the server with `claude mcp add --scope project`, which writes the repo's [`.mcp.json`](/docs/en/mcp#project-scope), and commit that file                                                                                                              |
| Transport variables in your repo's `.claude/settings.json` `env` block, such as `NODE_EXTRA_CA_CERTS` and the [mTLS client certificate variables](/docs/en/network-config#mtls-authentication) | No                          | The hosting environment manages the session's API connection, so Claude Code ignores these keys and notes each ignored key in the session's debug log                                                                                                                                                                |
| Static API tokens and credentials                                                                                                                                                         | No                          | No dedicated secrets store exists yet. See below                                                                                                                                                                                                                                                                     |
| Interactive auth like AWS SSO                                                                                                                                                             | No                          | Not supported. SSO requires browser-based login that can't run in a cloud session                                                                                                                                                                                                                                    |

To make your own configuration available in cloud sessions, commit it to the repo.

A dedicated secrets store is not yet available, and the dialog warns against adding secrets or credentials: environment variables and setup scripts live in the environment configuration, where anyone who uses the environment can read them. If a session needs a credential anyway, add it with that visibility in mind.

### Installed tools

Cloud sessions come with common language runtimes, build tools, and databases pre-installed. The table below summarizes what's included by category.

| Category      | Included                                                                           |
| :------------ | :--------------------------------------------------------------------------------- |
| **Python**    | Python 3.x with pip, poetry, uv, black, mypy, pytest, ruff                         |
| **Node.js**   | 20, 21, and 22 via nvm, with npm, yarn, pnpm, bun¹, eslint, prettier, chromedriver |
| **Ruby**      | 3.1, 3.2, 3.3 with gem, bundler, rbenv                                             |
| **PHP**       | 8.4 with Composer                                                                  |
| **Java**      | OpenJDK 21 with Maven and Gradle                                                   |
| **Go**        | latest stable with module support                                                  |
| **Rust**      | rustc and cargo                                                                    |
| **C/C++**     | GCC, Clang, cmake, ninja, conan                                                    |
| **Docker**    | docker, dockerd, docker compose                                                    |
| **Databases** | PostgreSQL 16, Redis 7.0                                                           |
| **Utilities** | git, jq, yq, ripgrep, tmux, vim, nano                                              |

¹ Bun is installed but has known [proxy compatibility issues](#install-dependencies-with-a-sessionstart-hook) for package fetching.

For exact versions, ask Claude to run `check-tools` in a cloud session. It's a shell command installed on the session VM, not a slash command; you ask Claude because [Claude runs all VM commands for you](#run-tests-start-services-and-add-packages).

Toolchains outside this list, such as the .NET SDK, aren't pre-installed even when their package registries are on the [default allowlist](#default-allowed-domains). Install them with a [setup script](#setup-scripts).

### Work with GitHub issues and pull requests

Cloud sessions include built-in GitHub tools that let Claude read issues, list pull requests, fetch diffs, and post comments without any setup. These tools authenticate through the [GitHub proxy](#github-proxy) using whichever method you configured under [GitHub authentication options](/docs/en/claude-code-on-the-web#github-authentication-options), so your token never enters the container.

You can set `GH_TOKEN` or `GITHUB_TOKEN` yourself in [environment settings](#set-environment-variables), or leave both unset and let the [GitHub proxy](#github-proxy) authenticate for you:

* If you set a token, it passes through to the container unchanged, so your scripts, and GitHub's [`gh` CLI](https://cli.github.com) if you install it, use it directly.
* If you set neither and the [GitHub proxy](#github-proxy) is handling authentication for your session, both variables read as the placeholder string `proxy-injected` in the commands Claude runs, and the proxy substitutes your real credentials on outbound GitHub requests. `gh` works without a token of your own, but a script that reads `GITHUB_TOKEN` directly gets the placeholder, not a usable token.

A token you set is an ordinary environment variable, so anyone who uses the environment can read it; the proxy path keeps the credential out of the environment configuration and the session VM.

To check which case applies to your session, ask Claude to run `echo $GH_TOKEN`.

GitHub's [`gh` CLI](https://cli.github.com) isn't pre-installed. If you need a `gh` command the built-in tools don't cover, like `gh release` or `gh workflow run`, install and authenticate it yourself:

  

    Add `apt update && apt install -y gh` to your [setup script](#setup-scripts).
  

  

    If `echo $GH_TOKEN` prints `proxy-injected`, the [GitHub proxy](#github-proxy) authenticates `gh` for you and this step is unnecessary. Otherwise, add a `GH_TOKEN` environment variable to your [environment settings](#set-environment-variables) with a GitHub personal access token; like any environment variable, it's readable by anyone who uses the environment, so scope the token narrowly. `gh` reads `GH_TOKEN` automatically, so you don't need to run `gh auth login`.
  

### Link output back to the session

Each cloud session has a transcript URL on claude.ai, and the session can read its own ID from the `CLAUDE_CODE_REMOTE_SESSION_ID` environment variable. Use this to put a traceable link in PR bodies, commit messages, Slack posts, or generated reports so a reviewer can open the run that produced them.

Commits that Claude creates in a cloud session include a `Claude-Session: <url>` git trailer, and PR bodies include the session URL on its own line. This requires v2.1.179 or later. {/* min-version: 2.1.182 */}To omit the trailer and the PR-body link, set [`attribution.sessionUrl`](/docs/en/settings#attribution-settings) to `false`. The setting requires v2.1.182 or later.

To include the session link in something other than a commit or PR, such as a Slack message Claude posts or a report file it writes, have Claude run the following command and use its output. The command converts the `cse_` prefix in the environment variable's value to the `session_` prefix that the transcript URL expects:

### Run tests, start services, and add packages

You don't get a shell into the session VM. Claude runs every command for you, so phrase the tasks in this section as requests in your prompt.

#### Run tests

Claude runs tests as part of working on a task. Ask for it in your prompt, like "fix the failing tests in `tests/`" or "run pytest after each change." Test runners that come with the [pre-installed toolchains](#installed-tools), like pytest and cargo test, work without additional setup. A runner your project declares as a dependency, like jest, installs with your dependencies.

#### Start services

PostgreSQL and Redis are pre-installed but not running by default. Ask Claude to start whichever you need; the commands it runs are:

Docker is available for running containerized services. Ask Claude to run `docker compose up` to start your project's services. Network access to pull images follows your environment's [access level](#access-levels), and the [Trusted defaults](#default-allowed-domains) include Docker Hub and other common registries.

If your images are large or slow to pull, add `docker compose pull` or `docker compose build` to your [setup script](#setup-scripts). The [environment cache](#environment-caching) keeps the pulled images, so each new session has them on disk. The cache stores files only, not running processes, so Claude still starts the containers each session.

#### Add packages

To add packages that aren't pre-installed, use a [setup script](#setup-scripts). The [environment cache](#environment-caching) keeps what the script installs, so packages you install there are available at the start of every session without reinstalling each time. You can also ask Claude to install packages mid-session, but those installs don't carry over to other sessions.

### Resource limits

Cloud sessions run with approximate resource ceilings that may change over time:

* 4 vCPUs
* 16 GB of RAM
* 30 GB of disk

The VM may stop tasks that need significantly more memory, such as large build jobs or memory-intensive tests. For workloads beyond these limits, use [Remote Control](/docs/en/remote-control) to run Claude Code on your own hardware.

## Setup scripts

A setup script is a Bash script that runs when a new cloud session starts, before Claude Code launches. Use setup scripts to install dependencies, configure tools, or fetch anything the session needs that isn't pre-installed.

Scripts run as root on Ubuntu 24.04, so `apt install` and most language package managers work.

To add a setup script, open the environment settings dialog and enter your script in the **Setup script** field.

This example installs GitHub's [`gh` CLI](https://cli.github.com), which isn't pre-installed.

### Script requirements

A setup script has three constraints to write around:

* **Exit zero**: if the script exits non-zero, the session fails to start. Append `|| true` to non-critical commands so an intermittent install failure doesn't block the session.
* **Finish within five minutes**: keep the script's total runtime under roughly five minutes so the [environment cache](#environment-caching) can build. Run independent installs in parallel with `&` and `wait`, and move any single download that won't fit into a [SessionStart hook](#setup-scripts-vs-sessionstart-hooks) that launches it in the background.
* **Network access for installs**: package installs need to reach registries. The default **Trusted** level covers [common package registries](#default-allowed-domains) including npm, PyPI, RubyGems, and crates.io; with **None** network access, installs fail.

### Environment caching

The setup script runs the first time you start a session in an environment. After it completes, Anthropic snapshots the filesystem and reuses that snapshot as the starting point for later sessions. New sessions start with your dependencies, tools, and Docker images already on disk, and skip the setup script step. This keeps startup fast even when the script installs large toolchains or pulls container images.

The cache is a filesystem snapshot, so it keeps what the setup script writes to disk and loses anything that was only running. Packages you install, Docker images you pull, and files you write all carry over. A database the script started, a `docker compose up` stack, or any other background process doesn't; start those per session by asking Claude or with a [SessionStart hook](#setup-scripts-vs-sessionstart-hooks).

The setup script runs again to rebuild the cache when you change the environment's setup script or allowed network hosts, and when the cache reaches its expiry after roughly seven days. Resuming an existing session never re-runs the setup script.

You don't need to enable caching or manage snapshots yourself.

### Setup scripts vs. SessionStart hooks

Use a setup script to provision the VM itself: toolchains and CLI tools that aren't [pre-installed](#installed-tools). Use a [SessionStart hook](/docs/en/hooks#sessionstart) for project setup that should run everywhere, cloud and local, like `npm install`.

Setup scripts and SessionStart hooks run in a fixed order when a cloud session starts:

1. The setup script runs first, before Claude Code launches, and only when no [cached environment](#environment-caching) exists.
2. Claude Code launches and runs your SessionStart hooks, as it does at the start of every session, local or cloud.

|                              | Setup scripts                                                                                 | SessionStart hooks                                                                                                                                                                                            |
| ---------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Where you configure them** | The environment dialog at [claude.ai/code](https://claude.ai/code)                            | A [settings file](/docs/en/settings#settings-files) such as your repo's `.claude/settings.json`; see [What carries over from your setup](#what-carries-over-from-your-setup) for which files reach a cloud session |
| **When they run**            | Before Claude Code launches, skipped when a [cached environment](#environment-caching) exists | After Claude Code launches, on every session including resumed                                                                                                                                                |
| **Where they run**           | Cloud sessions only                                                                           | Local and cloud sessions                                                                                                                                                                                      |

If you have SessionStart hooks in your user-level `~/.claude/settings.json`, don't expect them in the cloud: user-level settings stay on your machine. In a cloud session, Claude Code runs hooks from the repository and from your organization's [server-managed settings](/docs/en/server-managed-settings).

### Install dependencies with a SessionStart hook

To install dependencies only in cloud sessions, pair a SessionStart hook with a script that checks where it's running.

First, add a SessionStart hook to your repo's `.claude/settings.json`. This configuration tells Claude Code to run `scripts/install_pkgs.sh` from your repository whenever a session starts or resumes:

The `matcher` limits the hook to the `startup` and `resume` events, and `$CLAUDE_PROJECT_DIR` resolves to the repository root, so the hook finds the script regardless of the session's working directory.

Next, create the script at `scripts/install_pkgs.sh`. It exits immediately outside the cloud, then installs your dependencies:

Configure cloud environments

핵심 요약

Configure cloud environments for Claude Code cloud sessions: network access levels, environment variables, setup scripts, and environment caching.

한국어 가이드 범위: cloud-environments 경로의 설정·명령·제약·예시를 학습용으로 재구성합니다.

문서 구성

공식 문서의 주요 섹션은 다음과 같습니다.

Configure cloud environments
The Default environment
Configure your environment
Set environment variables
Select an environment from the CLI
Archive an environment
Organization-shared environments
Network access
Access levels
Allow specific domains
GitHub proxy
Security proxy
What's available in cloud sessions
What carries over from your setup
Installed tools
Work with GitHub issues and pull requests
Link output back to the session
Run tests, start services, and add packages
Resource limits
Setup scripts
Script requirements
Environment caching
Setup scripts vs. SessionStart hooks
Install dependencies with a SessionStart hook
Default allowed domains
Related resources

상세 내용

Configure cloud environments

The Default environment

주요 항목:

Trusted network access: sessions reach package registries and other allowlisted domains, and nothing else through the session's network.
No other configuration: Default defines no environment variables or setup script, so sessions start with just the pre-installed tools.
On the web, the Desktop app, and the mobile app, sessions use the environment shown in the selector. An admin-set organization default fills the selection when you haven't picked one.
From the CLI, sessions use your /remote-env pick, or fall back to your first available cloud environment.

Configure your environment

Set environment variables

Select an environment from the CLI

Archive an environment

To archive an environment, open it for editing and select Archive. You can't delete an environment, only archive it.

주요 항목:

Sessions already running in the environment continue to work.
The environment disappears from the selector and from /remote-env, so you can't pick it for new sessions.
No new session can start in an archived environment, on any surface. If the environment was your saved CLI default, CLI cloud sessions fall back to your first available cloud environment. Anything configured with the environment explicitly, such as a routine, can't start new sessions in it; point it at another environment.

Organization-shared environments

Network access

Access levels

The Network access field in the environment dialog takes one of four levels:

Level	Outbound connections
None	No outbound network access through the session's network
Trusted	Allowlisted domains only: package registries, GitHub, cloud SDKs
Full	Any domain
Custom	Your own allowlist, optionally including the defaults

Allow specific domains

GitHub proxy

All GitHub operations go through a dedicated proxy that keeps your real GitHub credentials outside the session's VM, independent of the environment's access level:

주요 항목:

Git credentials: the git client inside the VM uses a scoped credential, which the proxy verifies and swaps for your actual GitHub token.
API requests: requests from the built-in GitHub tools, and from gh under the proxy-injected placeholder, go out with your real credentials substituted.
Push protection: git push works only against the session's current working branch; cloning, fetching, and PR operations work normally.
Repository scope: GitHub API and release-asset requests reach only repositories attached to the session, so a setup script that downloads release assets from an unattached repository gets a 403.

Security proxy

Cloud sessions run behind an HTTP/HTTPS network proxy for security and abuse prevention purposes. All outbound internet traffic passes through this proxy, which provides:

주요 항목:

Protection against malicious requests
Rate limiting and abuse prevention
Content filtering for enhanced security
A DNS-level audit trail of requested hostnames

What's available in cloud sessions

What carries over from your setup

	Available in cloud sessions	Why
Your repo's `CLAUDE.md`	Yes	Part of the clone
Your repo's `.claude/settings.json` hooks	Yes	Part of the clone
Your repo's `.mcp.json` MCP servers	Yes	Part of the clone
Your repo's `.claude/rules/`	Yes	Part of the clone
Your repo's `.claude/skills/`, `.claude/agents/`, `.claude/commands/`	Yes	Part of the clone
Plugins declared in `.claude/settings.json`	Yes	Installed at session start from the marketplace you declared. Requires network access to reach the marketplace source
Your organization's server-managed settings	Yes	Fetched from Anthropic's servers when the session starts. See Surface coverage for how `availableModels` is enforced in cloud sessions. Settings deployed to your device through MDM or managed settings files don't apply, because the session runs on an Anthropic-managed VM
Your user `~/.claude/CLAUDE.md`	No	Lives on your machine, not in the repo
Your user `~/.claude/skills/`, `~/.claude/agents/`, `~/.claude/commands/`	No	Live on your machine, not in the repo. Commit them to the repo's `.claude/` directory instead. Cloud sessions automatically load skills you enable on claude.ai
Plugins enabled only in your user settings	No	User-scoped `enabledPlugins` lives in `~/.claude/settings.json`. Declare them in the repo's `.claude/settings.json` instead
MCP servers you added with `claude mcp add` at the default local scope or the user scope	No	Those write to `~/.claude.json` on your machine, not the repo. Add the server with `claude mcp add --scope project`, which writes the repo's `.mcp.json`, and commit that file
Transport variables in your repo's `.claude/settings.json` `env` block, such as `NODE_EXTRA_CA_CERTS` and the mTLS client certificate variables	No	The hosting environment manages the session's API connection, so Claude Code ignores these keys and notes each ignored key in the session's debug log
Static API tokens and credentials	No	No dedicated secrets store exists yet. See below
Interactive auth like AWS SSO	No	Not supported. SSO requires browser-based login that can't run in a cloud session

Installed tools

Cloud sessions come with common language runtimes, build tools, and databases pre-installed. The table below summarizes what's included by category.

Category	Included
Python	Python 3.x with pip, poetry, uv, black, mypy, pytest, ruff
Node.js	20, 21, and 22 via nvm, with npm, yarn, pnpm, bun¹, eslint, prettier, chromedriver
Ruby	3.1, 3.2, 3.3 with gem, bundler, rbenv
PHP	8.4 with Composer
Java	OpenJDK 21 with Maven and Gradle
Go	latest stable with module support
Rust	rustc and cargo
C/C++	GCC, Clang, cmake, ninja, conan
Docker	docker, dockerd, docker compose
Databases	PostgreSQL 16, Redis 7.0
Utilities	git, jq, yq, ripgrep, tmux, vim, nano

Work with GitHub issues and pull requests

주요 항목:

If you set a token, it passes through to the container unchanged, so your scripts, and GitHub's gh CLI if you install it, use it directly.
If you set neither and the GitHub proxy is handling authentication for your session, both variables read as the placeholder string proxy-injected in the commands Claude runs, and the proxy substitutes your real credentials on outbound GitHub requests. gh works without a token of your own, but a script that reads GITHUB_TOKEN directly gets the placeholder, not a usable token.

Link output back to the session

Run tests, start services, and add packages

You don't get a shell into the session VM. Claude runs every command for you, so phrase the tasks in this section as requests in your prompt.

Resource limits

Cloud sessions run with approximate resource ceilings that may change over time:

주요 항목:

4 vCPUs
16 GB of RAM
30 GB of disk

Setup scripts

Script requirements

A setup script has three constraints to write around:

주요 항목:

Exit zero: if the script exits non-zero, the session fails to start. Append || true to non-critical commands so an intermittent install failure doesn't block the session.
Finish within five minutes: keep the script's total runtime under roughly five minutes so the environment cache can build. Run independent installs in parallel with & and wait, and move any single download that won't fit into a SessionStart hook that launches it in the background.
Network access for installs: package installs need to reach registries. The default Trusted level covers common package registries including npm, PyPI, RubyGems, and crates.io; with None network access, installs fail.

Environment caching

Setup scripts vs. SessionStart hooks

	Setup scripts	SessionStart hooks
Where you configure them	The environment dialog at claude.ai/code	A settings file such as your repo's `.claude/settings.json`; see What carries over from your setup for which files reach a cloud session
When they run	Before Claude Code launches, skipped when a cached environment exists	After Claude Code launches, on every session including resumed
Where they run	Cloud sessions only	Local and cloud sessions

Install dependencies with a SessionStart hook

To install dependencies only in cloud sessions, pair a SessionStart hook with a script that checks where it's running.

주요 항목:

No cloud-only scoping: hooks run in both local and cloud sessions. To skip local execution, check the CLAUDE_CODE_REMOTE environment variable as shown above.
Requires network access: install commands need to reach package registries. If your environment uses None network access, these hooks fail. The default allowlist under Trusted covers npm, PyPI, RubyGems, and crates.io.
Proxy compatibility: all outbound traffic passes through a security proxy. Some package managers don't work correctly with this proxy. Bun is a known example.
Adds startup latency: hooks run each time a session starts or resumes, unlike setup scripts which benefit from environment caching. Keep install scripts fast by checking whether dependencies are already present before reinstalling.

The `matcher` limits the hook to the `startup` and `resume` events, and `$CLAUDE_PROJECT_DIR` resolves to the repository root, so the hook finds the script regardless of the session's working directory.

Next, create the script at `scripts/install_pkgs.sh`. It exits immediately outside the cloud, then installs your dependencies:

Default allowed domains

With Trusted network access, sessions can reach the following domains by default. Domains marked with * indicate wildcard subdomain matching, so *.gcr.io allows any subdomain of gcr.io.

주요 항목:

api.anthropic.com
statsig.anthropic.com
docs.claude.com
platform.claude.com
code.claude.com
claude.ai
github.com
www.github.com
api.github.com
npm.pkg.github.com
raw.githubusercontent.com
pkg-npm.githubusercontent.com
objects.githubusercontent.com
release-assets.githubusercontent.com
codeload.github.com
avatars.githubusercontent.com
camo.githubusercontent.com
gist.github.com
gitlab.com
www.gitlab.com
registry.gitlab.com
bitbucket.org
www.bitbucket.org
api.bitbucket.org
registry-1.docker.io
auth.docker.io
index.docker.io
hub.docker.com
www.docker.com
production.cloudflare.docker.com

주요 항목:

Claude Code on the web: start, manage, and share cloud sessions
Web quickstart: connect GitHub and start your first cloud session
Claude Tag: sessions Claude starts from Slack run in the same environments
Routines: scheduled runs use the same environments and network access levels
Remote Control: run sessions on your own machine's network and files instead
SessionStart hooks: repo-committed setup that runs in local and cloud sessions
Server-managed settings: organization policy that reaches cloud sessions

실습 체크리스트

공식 문서와 로컬/SDK 버전을 대조합니다.
관련 CLI·SDK 옵션은 공식 페이지와 --help로 교차 확인합니다.
Agent SDK 예시는 TypeScript/Python 패키지 최신 API를 우선합니다.
권한·호스팅·보안 설정 변경 후 통합 테스트를 실행합니다.

자주 쓰는 명령·설정 예시

Each session copies the environment's values once, at startup, into ordinary environment variables that any command Claude runs can read. Because running sessions don't re-read the configuration, editing or adding variables affects sessions you start afterward; sessions already running keep the values they started with.

Anyone who uses the environment can read the values, and cloud environments have no dedicated secrets store, so don't add API keys or other credentials. If a session needs a credential anyway, see [What carries over from your setup](#what-carries-over-from-your-setup).

### Select an environment from the CLI

Run `/remote-env` in your terminal to choose the default environment for cloud sessions you create from the CLI, such as [`claude --cloud`](/docs/en/claude-code-on-the-web#from-terminal-to-web). The command opens a picker of your existing environments and saves your choice to the `remote.defaultEnvironmentId` key in your [user settings](/docs/en/settings#settings-files), so it applies in every project on your machine until you change it, unless the same key is set at a higher-precedence [settings layer](/docs/en/settings#settings-precedence), such as a repo's project settings.

`/remote-env` only sets the default: it doesn't start a session, and it can't add or edit environments. Manage them at [claude.ai/code](https://claude.ai/code).

### Archive an environment

To archive an environment, open it for editing and select **Archive**. You can't delete an environment, only archive it.

Archiving affects new sessions, not running ones:

* Sessions already running in the environment continue to work.
* The environment disappears from the selector and from `/remote-env`, so you can't pick it for new sessions.
* No new session can start in an archived environment, on any surface. If the environment was your saved [CLI default](#select-an-environment-from-the-cli), CLI cloud sessions fall back to your first available cloud environment. Anything configured with the environment explicitly, such as a [routine](/docs/en/routines#environments-and-network-access), can't start new sessions in it; point it at another environment.

### Organization-shared environments

Owners and admins on Team and Enterprise plans can create cloud environments that are shared with every member of the organization. Shared environments appear in each member's environment selector alongside their personal ones, so a team can standardize on one configuration instead of each member recreating it.

Create, edit, and archive shared environments from the **Cloud environments** page in [admin settings](https://claude.ai/admin-settings). Each shared environment has a name, a [network access level](#access-levels), [environment variables](#set-environment-variables) in `.env` format, and a [setup script](#setup-scripts). Owners and admins choose the organization's [default environment](#the-default-environment) separately, at [claude.ai/admin-settings/claude-code](https://claude.ai/admin-settings/claude-code).

Values in a shared environment reach every member's sessions in that environment. Like personal environments, shared environments have no dedicated secrets store, so don't include secrets.

Shared environments add to members' selectors rather than replacing them.

## Network access

Each environment sets one network access level, which controls the outbound connections its sessions can make. The default level, **Trusted**, allows package registries and other [allowlisted domains](#default-allowed-domains); **Custom** takes your own domain list.

To change an environment's network access, [open it for editing](#configure-your-environment) and use the **Network access** selector in the dialog. The cloud icon that opens the selector appears on the app surfaces listed under [The Default environment](#the-default-environment) and in the [routine editor](/docs/en/routines#environments-and-network-access); personal environments don't have a separate page in your claude.ai account settings.

  MCP connectors you enable on a session or routine work without adding their hosts to **Allowed domains**, because connector traffic travels through Anthropic's servers rather than the session's network. You configure connectors per session or per routine; remove any you don't need to limit which tools Claude can reach. This relies on the same Anthropic-bound channel noted under [Security and isolation](/docs/en/claude-code-on-the-web#security-and-isolation).

### Access levels

The **Network access** field in the [environment dialog](#configure-your-environment) takes one of four levels:

| Level       | Outbound connections                                                                         |
| :---------- | :------------------------------------------------------------------------------------------- |
| **None**    | No outbound network access through the session's network                                     |
| **Trusted** | [Allowlisted domains](#default-allowed-domains) only: package registries, GitHub, cloud SDKs |
| **Full**    | Any domain                                                                                   |
| **Custom**  | Your own allowlist, optionally including the defaults                                        |

GitHub operations use a [separate proxy](#github-proxy) that is independent of this setting, and Claude Code's connection to the Anthropic API still works at **None**, as noted under [Security and isolation](/docs/en/claude-code-on-the-web#security-and-isolation).

### Allow specific domains

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

Sessions in this environment can now reach `api.example.com`, any subdomain of `internal.example.com`, and `registry.example.com`, and no other domains through the session's network; [GitHub traffic](#github-proxy) and [MCP connector traffic](#network-access) don't go through this allowlist. A leading `*.` matches every subdomain. To keep the [Trusted domains](#default-allowed-domains) too, check **Also include default list of common package managers**; leave it unchecked to allow only what you list.

Each environment has its own allowed-domains list; there's no organization-level allowlist that admins can push to every member's environments. [Server-managed settings](/docs/en/server-managed-settings) still apply inside cloud sessions, but none of them adds domains to the environment's network allowlist.

### GitHub proxy

All GitHub operations go through a dedicated proxy that keeps your real GitHub credentials outside the session's VM, independent of the environment's [access level](#access-levels):

* **Git credentials**: the git client inside the VM uses a scoped credential, which the proxy verifies and swaps for your actual GitHub token.
* **API requests**: requests from the built-in GitHub tools, and from `gh` under the [`proxy-injected` placeholder](#work-with-github-issues-and-pull-requests), go out with your real credentials substituted.
* **Push protection**: `git push` works only against the session's current working branch; cloning, fetching, and PR operations work normally.
* **Repository scope**: GitHub API and release-asset requests reach only repositories attached to the session, so a setup script that downloads release assets from an unattached repository gets a 403.

Committed files from public repositories arrive through `raw.githubusercontent.com`, which the [security proxy](#security-proxy) handles instead. That domain is in the default [Trusted list](#default-allowed-domains), so those files stay reachable unless the environment's [access level](#access-levels) excludes it.

### Security proxy

Cloud sessions run behind an HTTP/HTTPS network proxy for security and abuse prevention purposes. All outbound internet traffic passes through this proxy, which provides:

* Protection against malicious requests
* Rate limiting and abuse prevention
* Content filtering for enhanced security
* A DNS-level audit trail of requested hostnames

## What's available in cloud sessions

Each session gets a fresh virtual machine (VM) running Ubuntu 24.04, regardless of your own operating system, with your repository cloned and common toolchains pre-installed. This section covers those defaults, the built-in GitHub tools, how to [run tests and services](#run-tests-start-services-and-add-packages), and the [resource limits](#resource-limits) each VM gets.

### What carries over from your setup

Cloud sessions start from a fresh clone of your repository. Anything you commit to the repo is available. Anything you've installed or configured only on your own machine isn't available in the session. Your organization's policy arrives separately through [server-managed settings](/docs/en/server-managed-settings).

|                                                                                                                                                                                           | Available in cloud sessions | Why                                                                                                                                                                                                                                                                                                                  |
| :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Your repo's `CLAUDE.md`                                                                                                                                                                   | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.claude/settings.json` hooks                                                                                                                                                 | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.mcp.json` MCP servers                                                                                                                                                       | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.claude/rules/`                                                                                                                                                              | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Your repo's `.claude/skills/`, `.claude/agents/`, `.claude/commands/`                                                                                                                     | Yes                         | Part of the clone                                                                                                                                                                                                                                                                                                    |
| Plugins declared in `.claude/settings.json`                                                                                                                                               | Yes                         | Installed at session start from the [marketplace](/docs/en/plugin-marketplaces) you declared. Requires network access to reach the marketplace source                                                                                                                                                                     |
| Your organization's [server-managed settings](/docs/en/server-managed-settings)                                                                                                                | Yes                         | Fetched from Anthropic's servers when the session starts. See [Surface coverage](/docs/en/model-config#surface-coverage) for how `availableModels` is enforced in cloud sessions. Settings deployed to your device through MDM or managed settings files don't apply, because the session runs on an Anthropic-managed VM |
| Your user `~/.claude/CLAUDE.md`                                                                                                                                                           | No                          | Lives on your machine, not in the repo                                                                                                                                                                                                                                                                               |
| Your user `~/.claude/skills/`, `~/.claude/agents/`, `~/.claude/commands/`                                                                                                                 | No                          | Live on your machine, not in the repo. Commit them to the repo's `.claude/` directory instead. Cloud sessions automatically load skills you enable on claude.ai                                                                                                                                                      |
| Plugins enabled only in your user settings                                                                                                                                                | No                          | User-scoped `enabledPlugins` lives in `~/.claude/settings.json`. Declare them in the repo's `.claude/settings.json` instead                                                                                                                                                                                          |
| MCP servers you added with `claude mcp add` at the default local scope or the user scope                                                                                                  | No                          | Those write to `~/.claude.json` on your machine, not the repo. Add the server with `claude mcp add --scope project`, which writes the repo's [`.mcp.json`](/docs/en/mcp#project-scope), and commit that file                                                                                                              |
| Transport variables in your repo's `.claude/settings.json` `env` block, such as `NODE_EXTRA_CA_CERTS` and the [mTLS client certificate variables](/docs/en/network-config#mtls-authentication) | No                          | The hosting environment manages the session's API connection, so Claude Code ignores these keys and notes each ignored key in the session's debug log                                                                                                                                                                |
| Static API tokens and credentials                                                                                                                                                         | No                          | No dedicated secrets store exists yet. See below                                                                                                                                                                                                                                                                     |
| Interactive auth like AWS SSO                                                                                                                                                             | No                          | Not supported. SSO requires browser-based login that can't run in a cloud session                                                                                                                                                                                                                                    |

To make your own configuration available in cloud sessions, commit it to the repo.

A dedicated secrets store is not yet available, and the dialog warns against adding secrets or credentials: environment variables and setup scripts live in the environment configuration, where anyone who uses the environment can read them. If a session needs a credential anyway, add it with that visibility in mind.

### Installed tools

Cloud sessions come with common language runtimes, build tools, and databases pre-installed. The table below summarizes what's included by category.

| Category      | Included                                                                           |
| :------------ | :--------------------------------------------------------------------------------- |
| **Python**    | Python 3.x with pip, poetry, uv, black, mypy, pytest, ruff                         |
| **Node.js**   | 20, 21, and 22 via nvm, with npm, yarn, pnpm, bun¹, eslint, prettier, chromedriver |
| **Ruby**      | 3.1, 3.2, 3.3 with gem, bundler, rbenv                                             |
| **PHP**       | 8.4 with Composer                                                                  |
| **Java**      | OpenJDK 21 with Maven and Gradle                                                   |
| **Go**        | latest stable with module support                                                  |
| **Rust**      | rustc and cargo                                                                    |
| **C/C++**     | GCC, Clang, cmake, ninja, conan                                                    |
| **Docker**    | docker, dockerd, docker compose                                                    |
| **Databases** | PostgreSQL 16, Redis 7.0                                                           |
| **Utilities** | git, jq, yq, ripgrep, tmux, vim, nano                                              |

¹ Bun is installed but has known [proxy compatibility issues](#install-dependencies-with-a-sessionstart-hook) for package fetching.

For exact versions, ask Claude to run `check-tools` in a cloud session. It's a shell command installed on the session VM, not a slash command; you ask Claude because [Claude runs all VM commands for you](#run-tests-start-services-and-add-packages).

Toolchains outside this list, such as the .NET SDK, aren't pre-installed even when their package registries are on the [default allowlist](#default-allowed-domains). Install them with a [setup script](#setup-scripts).

### Work with GitHub issues and pull requests

Cloud sessions include built-in GitHub tools that let Claude read issues, list pull requests, fetch diffs, and post comments without any setup. These tools authenticate through the [GitHub proxy](#github-proxy) using whichever method you configured under [GitHub authentication options](/docs/en/claude-code-on-the-web#github-authentication-options), so your token never enters the container.

You can set `GH_TOKEN` or `GITHUB_TOKEN` yourself in [environment settings](#set-environment-variables), or leave both unset and let the [GitHub proxy](#github-proxy) authenticate for you:

* If you set a token, it passes through to the container unchanged, so your scripts, and GitHub's [`gh` CLI](https://cli.github.com) if you install it, use it directly.
* If you set neither and the [GitHub proxy](#github-proxy) is handling authentication for your session, both variables read as the placeholder string `proxy-injected` in the commands Claude runs, and the proxy substitutes your real credentials on outbound GitHub requests. `gh` works without a token of your own, but a script that reads `GITHUB_TOKEN` directly gets the placeholder, not a usable token.

A token you set is an ordinary environment variable, so anyone who uses the environment can read it; the proxy path keeps the credential out of the environment configuration and the session VM.

To check which case applies to your session, ask Claude to run `echo $GH_TOKEN`.

GitHub's [`gh` CLI](https://cli.github.com) isn't pre-installed. If you need a `gh` command the built-in tools don't cover, like `gh release` or `gh workflow run`, install and authenticate it yourself:

  

    Add `apt update && apt install -y gh` to your [setup script](#setup-scripts).
  

  

    If `echo $GH_TOKEN` prints `proxy-injected`, the [GitHub proxy](#github-proxy) authenticates `gh` for you and this step is unnecessary. Otherwise, add a `GH_TOKEN` environment variable to your [environment settings](#set-environment-variables) with a GitHub personal access token; like any environment variable, it's readable by anyone who uses the environment, so scope the token narrowly. `gh` reads `GH_TOKEN` automatically, so you don't need to run `gh auth login`.
  

### Link output back to the session

Each cloud session has a transcript URL on claude.ai, and the session can read its own ID from the `CLAUDE_CODE_REMOTE_SESSION_ID` environment variable. Use this to put a traceable link in PR bodies, commit messages, Slack posts, or generated reports so a reviewer can open the run that produced them.

Commits that Claude creates in a cloud session include a `Claude-Session: <url>` git trailer, and PR bodies include the session URL on its own line. This requires v2.1.179 or later. {/* min-version: 2.1.182 */}To omit the trailer and the PR-body link, set [`attribution.sessionUrl`](/docs/en/settings#attribution-settings) to `false`. The setting requires v2.1.182 or later.

To include the session link in something other than a commit or PR, such as a Slack message Claude posts or a report file it writes, have Claude run the following command and use its output. The command converts the `cse_` prefix in the environment variable's value to the `session_` prefix that the transcript URL expects:

### Run tests, start services, and add packages

You don't get a shell into the session VM. Claude runs every command for you, so phrase the tasks in this section as requests in your prompt.

#### Run tests

Claude runs tests as part of working on a task. Ask for it in your prompt, like "fix the failing tests in `tests/`" or "run pytest after each change." Test runners that come with the [pre-installed toolchains](#installed-tools), like pytest and cargo test, work without additional setup. A runner your project declares as a dependency, like jest, installs with your dependencies.

#### Start services

PostgreSQL and Redis are pre-installed but not running by default. Ask Claude to start whichever you need; the commands it runs are:

Docker is available for running containerized services. Ask Claude to run `docker compose up` to start your project's services. Network access to pull images follows your environment's [access level](#access-levels), and the [Trusted defaults](#default-allowed-domains) include Docker Hub and other common registries.

If your images are large or slow to pull, add `docker compose pull` or `docker compose build` to your [setup script](#setup-scripts). The [environment cache](#environment-caching) keeps the pulled images, so each new session has them on disk. The cache stores files only, not running processes, so Claude still starts the containers each session.

#### Add packages

To add packages that aren't pre-installed, use a [setup script](#setup-scripts). The [environment cache](#environment-caching) keeps what the script installs, so packages you install there are available at the start of every session without reinstalling each time. You can also ask Claude to install packages mid-session, but those installs don't carry over to other sessions.

### Resource limits

Cloud sessions run with approximate resource ceilings that may change over time:

* 4 vCPUs
* 16 GB of RAM
* 30 GB of disk

The VM may stop tasks that need significantly more memory, such as large build jobs or memory-intensive tests. For workloads beyond these limits, use [Remote Control](/docs/en/remote-control) to run Claude Code on your own hardware.

## Setup scripts

A setup script is a Bash script that runs when a new cloud session starts, before Claude Code launches. Use setup scripts to install dependencies, configure tools, or fetch anything the session needs that isn't pre-installed.

Scripts run as root on Ubuntu 24.04, so `apt install` and most language package managers work.

To add a setup script, open the environment settings dialog and enter your script in the **Setup script** field.

This example installs GitHub's [`gh` CLI](https://cli.github.com), which isn't pre-installed.

### Script requirements

A setup script has three constraints to write around:

* **Exit zero**: if the script exits non-zero, the session fails to start. Append `|| true` to non-critical commands so an intermittent install failure doesn't block the session.
* **Finish within five minutes**: keep the script's total runtime under roughly five minutes so the [environment cache](#environment-caching) can build. Run independent installs in parallel with `&` and `wait`, and move any single download that won't fit into a [SessionStart hook](#setup-scripts-vs-sessionstart-hooks) that launches it in the background.
* **Network access for installs**: package installs need to reach registries. The default **Trusted** level covers [common package registries](#default-allowed-domains) including npm, PyPI, RubyGems, and crates.io; with **None** network access, installs fail.

### Environment caching

The setup script runs the first time you start a session in an environment. After it completes, Anthropic snapshots the filesystem and reuses that snapshot as the starting point for later sessions. New sessions start with your dependencies, tools, and Docker images already on disk, and skip the setup script step. This keeps startup fast even when the script installs large toolchains or pulls container images.

The cache is a filesystem snapshot, so it keeps what the setup script writes to disk and loses anything that was only running. Packages you install, Docker images you pull, and files you write all carry over. A database the script started, a `docker compose up` stack, or any other background process doesn't; start those per session by asking Claude or with a [SessionStart hook](#setup-scripts-vs-sessionstart-hooks).

The setup script runs again to rebuild the cache when you change the environment's setup script or allowed network hosts, and when the cache reaches its expiry after roughly seven days. Resuming an existing session never re-runs the setup script.

You don't need to enable caching or manage snapshots yourself.

### Setup scripts vs. SessionStart hooks

Use a setup script to provision the VM itself: toolchains and CLI tools that aren't [pre-installed](#installed-tools). Use a [SessionStart hook](/docs/en/hooks#sessionstart) for project setup that should run everywhere, cloud and local, like `npm install`.

Setup scripts and SessionStart hooks run in a fixed order when a cloud session starts:

1. The setup script runs first, before Claude Code launches, and only when no [cached environment](#environment-caching) exists.
2. Claude Code launches and runs your SessionStart hooks, as it does at the start of every session, local or cloud.

|                              | Setup scripts                                                                                 | SessionStart hooks                                                                                                                                                                                            |
| ---------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Where you configure them** | The environment dialog at [claude.ai/code](https://claude.ai/code)                            | A [settings file](/docs/en/settings#settings-files) such as your repo's `.claude/settings.json`; see [What carries over from your setup](#what-carries-over-from-your-setup) for which files reach a cloud session |
| **When they run**            | Before Claude Code launches, skipped when a [cached environment](#environment-caching) exists | After Claude Code launches, on every session including resumed                                                                                                                                                |
| **Where they run**           | Cloud sessions only                                                                           | Local and cloud sessions                                                                                                                                                                                      |

If you have SessionStart hooks in your user-level `~/.claude/settings.json`, don't expect them in the cloud: user-level settings stay on your machine. In a cloud session, Claude Code runs hooks from the repository and from your organization's [server-managed settings](/docs/en/server-managed-settings).

### Install dependencies with a SessionStart hook

To install dependencies only in cloud sessions, pair a SessionStart hook with a script that checks where it's running.

First, add a SessionStart hook to your repo's `.claude/settings.json`. This configuration tells Claude Code to run `scripts/install_pkgs.sh` from your repository whenever a session starts or resumes:

The `matcher` limits the hook to the `startup` and `resume` events, and `$CLAUDE_PROJECT_DIR` resolves to the repository root, so the hook finds the script regardless of the session's working directory.

Next, create the script at `scripts/install_pkgs.sh`. It exits immediately outside the cloud, then installs your dependencies:

Configure cloud environments

핵심 요약

문서 구성

상세 내용

Configure cloud environments

The Default environment

Configure your environment

Set environment variables

Select an environment from the CLI

Archive an environment

Organization-shared environments

Network access

Access levels

Allow specific domains

GitHub proxy

Security proxy

What's available in cloud sessions

What carries over from your setup

Installed tools

Work with GitHub issues and pull requests

Link output back to the session

Run tests, start services, and add packages

Resource limits

Setup scripts

Script requirements

Environment caching

Setup scripts vs. SessionStart hooks

Install dependencies with a SessionStart hook

Default allowed domains

Related resources

실습 체크리스트

자주 쓰는 명령·설정 예시

관련 링크

관련 가이드

Configure cloud environments

핵심 요약

문서 구성

상세 내용

Configure cloud environments

The Default environment

Configure your environment

Set environment variables

Select an environment from the CLI

Archive an environment

Organization-shared environments

Network access

Access levels

Allow specific domains

GitHub proxy

Security proxy

What's available in cloud sessions

What carries over from your setup

Installed tools

Work with GitHub issues and pull requests

Link output back to the session

Run tests, start services, and add packages

Resource limits

Setup scripts

Script requirements

Environment caching

Setup scripts vs. SessionStart hooks

Install dependencies with a SessionStart hook

Default allowed domains

Related resources

실습 체크리스트

자주 쓰는 명령·설정 예시

관련 링크

관련 가이드