· 6 min read
Claude Code cloud environment: pricing, setup scripts, secrets and network access
How the Claude Code cloud environment works: what cloud sessions cost on your plan, the machine you get, setup scripts and caching, environment variables and network secrets, network access levels, Docker and MCP, what carries over from your laptop, and when it's the wrong fit.
A Claude Code cloud environment is the configuration a cloud session starts from: a network access level, environment variables, network secrets and a setup script. Each session runs in a fresh Ubuntu 24.04 machine with about 4 vCPUs and 16 GB of RAM, and what it uses counts against your Claude plan's usage, like the rest of your Claude use.
What is a Claude Code cloud environment?
When you start a session at claude.ai/code, in the Claude app or with claude --cloud, Claude Code runs on a virtual machine Anthropic manages. The environment decides what that machine can reach and what is installed before Claude starts.
Your first environment is usually Default: Trusted network access, no variables and no setup script. Onboarding with /web-setup, or on the web with a Pro or Max plan, creates it for you.
To change it, open the environment selector under the message box on the new-session screen at claude.ai/code, and add or edit an environment. Environments you create are personal to your account. On Team and Enterprise, an Owner can also share environments with the whole organization. From the terminal, /remote-env picks the default environment for claude --cloud.
If you haven't decided whether cloud sessions are the right way to run Claude Code for your work, start with the best way to work with Claude Code in the cloud.
How much does Claude Code in the cloud cost?
Cloud sessions are part of the Pro, Max, Team and Enterprise plans, and Anthropic's docs describe their cost in terms of your plan's usage. They "share rate limits with all other Claude and Claude Code usage within your account", and parallel tasks use those limits up proportionately faster.
| What you run | What it draws on |
|---|---|
| A cloud session | Your plan's usage, shared with everything else |
| Several sessions in parallel | The same usage, used up faster |
| Cloud scheduled tasks | Your plan's usage, plus hourly run caps (100 scheduled runs an hour per account) |
| Past your plan's limit | Rejected until the window resets, unless your organization turns on usage credits |
Check your current consumption at claude.ai/settings/usage. The practical cost is timing: a usage limit reached at night stops the work until the window resets.
What machine does a Claude Code cloud session run on?
| Resource | Default |
|---|---|
| Operating system | Ubuntu 24.04, x86_64 |
| CPU and memory | About 4 vCPUs and 16 GB of RAM |
| Disk | About 30 GB |
| Command timeout | 2 minutes by default, up to 10 minutes on request |
| Long commands | Moved to the background, for up to 30 more minutes |
| Idle | Pauses after a few minutes with its files saved; a paused machine can be reclaimed later |
Python, Node.js 20 to 22, Ruby, PHP, Java, Go, Rust, C and C++ toolchains, Docker, PostgreSQL 16, Redis 7 and the usual utilities (git, gh, jq, ripgrep, tmux) come pre-installed. Ask Claude to run check-tools in a session for the exact versions. Anything else, such as the .NET SDK, goes in a setup script.
To raise the command timeouts, add BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS to the environment's variables. BASH_DEFAULT_TIMEOUT_MS=600000 makes 10 minutes the default.
How do I write a setup script for a Claude Code cloud environment?
A setup script is a Bash script that runs as root before Claude Code starts in a new session. Put it in the environment's Setup script field:
#!/bin/bash
apt update && apt install -y shellcheck
pip install pre-commit || true
Three rules keep it working:
- Exit zero. A non-zero exit stops the session from starting. Add
|| trueto anything optional. - Finish in about five minutes. Anthropic snapshots the disk after a setup script that finishes in time and starts later sessions from that snapshot, skipping the script. A slower script is never cached. Run independent installs in parallel with
&andwait. - Keep network access for installs. The default Trusted level reaches npm, PyPI, RubyGems and crates.io. With network access set to None, installs fail.
The snapshot keeps what is on disk: packages, files and pulled Docker images. It doesn't keep anything running, so start databases and docker compose stacks per session. The cache rebuilds when you change the script or the allowed hosts, and after about seven days.
For setup that should also run on your laptop, such as npm install, use a SessionStart hook in the repo's .claude/settings.json. Hooks in your personal ~/.claude/settings.json don't run in the cloud.
How do I add environment variables and secrets?
Environment variables go in the environment dialog in .env format, one KEY=value per line. Every command Claude runs can read them, and so can anyone who uses the environment, so they are the wrong place for a key.
Network secrets are the place for API keys. Anthropic's agent proxy adds the key to requests for the hosts you list after the request leaves the machine, so the key never sits inside the session:
- Open the environment for editing and find Network secrets.
- Select Add secret, name it, list the API's hosts (such as
api.example.com), and paste the key as the value of theAuthorizationheader. - Start a session and ask Claude to call the API with
curl. The call works, and the key appears in no variable or file.
You can't view or edit a secret after saving it; delete it and add it again. The proxy never attaches a secret to GitHub, the Anthropic API, public package registries or setup-script requests. Logins that need a browser, such as AWS SSO, aren't supported.
Secrets were a long-standing gap. An open request for "secure secrets injection for Claude Code on the web" has 212 reactions, and network secrets now cover the common case of an API key sent in a header.
What can a Claude Code cloud session reach on the network?
| Level | Outbound connections |
|---|---|
| None | No outbound access through the session's network |
| Trusted (default) | An allowlist: package registries, GitHub, cloud SDKs |
| Full | Any domain |
| Custom | Your own list of domains, optionally including the defaults |
Some paths work at every level: GitHub through its own proxy, MCP connectors (their traffic goes through Anthropic's servers), the hosts on your network secrets, and the Anthropic API. A change to the level reaches running sessions within about a minute.
Can I use Docker and MCP servers in a cloud session?
Docker: yes. docker, dockerd and docker compose are installed. Images pulled in the setup script are kept in the cached snapshot, and running containers are not, so start them in each session.
MCP servers: servers in the repo's .mcp.json load in a session with one repository. Servers you added on your laptop with claude mcp add at the default local or user scope stay on your laptop. Add them with claude mcp add --scope project and commit the .mcp.json. Connectors from claude.ai can be turned on per session.
What carries over from my laptop?
A cloud session starts from a fresh clone, so anything committed to the repo comes along and anything only on your machine doesn't.
| Carries over | Stays on your laptop |
|---|---|
The repo's CLAUDE.md and .claude/rules/ | Your personal ~/.claude/CLAUDE.md |
Hooks and permission rules in the repo's .claude/settings.json | Personal skills, agents and commands in ~/.claude/ |
Skills, agents and commands in the repo's .claude/ | Plugins, including ones a repo's settings turn on |
The repo's .mcp.json (one-repository sessions) | MCP servers added at local or user scope |
For personal preferences you don't want in a shared repo, have the setup script write ~/.claude/CLAUDE.md in one of your own environments. Run /context in the next session to confirm it loaded.
When is a cloud environment the wrong fit?
- The repo isn't on GitHub. A GitLab or Bitbucket repo can go up as a bundle, but the session can't push results back to it. An open request for GitLab support has 161 reactions.
- The job needs more than about 4 vCPUs and 16 GB. The docs point to Remote Control on your own hardware, or a self-hosted environment.
- It needs your private network. Self-hosted environments run sessions on your organization's machines (Team and Enterprise, in public beta). Otherwise, run Claude Code on your own VPS.
- It needs signed-in tools. Browser logins and SSO don't carry into the session.
- It has to run on a schedule or around the clock. Cloud scheduled tasks cover repo work hourly or less often; how to run Claude Code 24/7 compares the rest.
How is a Kavela agent's computer different?
Kavela gives each agent its own cloud computer (2 vCPU, 8 GiB) with a shell, files, git and a real browser, and runs Claude Code there on your own Claude plan. The computer sleeps about 2 minutes after a run with its files saved, and the next run picks up with the same files.
Files belong to the workspace, so every agent and every person in it works from the same files. The browser keeps its sign-ins between runs, and you can take it over at any time to sign in to something yourself. Connections to your other tools are made once for the workspace and every agent can use them, so the setup carries from one task to the next without a script.
Work starts from a message to Kav, the lead agent, from a schedule or from an event. Questions wait in one Approvals inbox you can answer from your phone, and every workflow run is checked by a second agent against your checklist before it reaches you.
Kavela starts with a 14-day free trial, no card. Start your free trial