Claude Code on the Web: Cloud Sessions vs the Terminal

Claude Code on the web, at claude.ai/code, runs Claude Code in the cloud instead of on your machine. You pick a GitHub repository and branch, describe a task, and Claude clones the repository into an isolated virtual machine, does the work, and pushes a branch you review as a diff and turn into a pull request. Each task is its own session on its own branch, so several run at once, and they keep going after you close the laptop. The terminal is still better for work that needs your local files, tools, credentials or a private network; the web is better for well-defined tasks you want to hand off and review later.

What it is, and what it is not

Anthropic’s cloud sessions documentation↗ (opens in a new tab) calls these cloud sessions: Claude Code sessions that run on infrastructure Anthropic manages, or on your organisation’s own self-hosted environment when it routes them there. They are available on Pro, Max and Team plans and to Enterprise users with the right seats. The browser is one way in; the same sessions start from the Code tab in the Claude mobile app, from the desktop app by choosing Cloud instead of Local, from the terminal with claude --cloud, and from routines.

It is not the same as steering your own computer from a browser. That is Remote Control, where the session still runs on your desk; the phone side of both is covered in Claude Code Remote Control, and how the local surfaces compare is in Claude Code desktop vs CLI vs VS Code. Cloud sessions are unavailable when Claude Code is configured for Amazon Bedrock, Google Cloud or another third-party provider, and organisations with Zero Data Retention cannot use them.

Repository access: two ways to connect GitHub

• The Claude GitHub App, authorised during web onboarding. Sessions can clone any public repository, and private repositories only where the app is installed; an organisation owner may need to approve the install. Installing it is also what enables auto-fix on pull requests.
• /web-setup in your terminal, which sends your local gh CLI token to your Claude account. Sessions can then reach any repository that token can, whether or not the app is installed. On Team and Enterprise plans this is hidden until an Owner turns on Quick web setup in the admin settings.

In Anthropic-hosted environments your GitHub credentials stay encrypted on Anthropic’s servers and never enter the VM; a GitHub proxy attaches them to requests on the server side. Inside the session, git push works only against the session’s own working branch, so Claude cannot push to main or any other branch.

Environments and setup scripts

Every session runs in a cloud environment: a saved configuration with a network level, environment variables and a setup script. Onboarding gives you a Default environment with no variables and no script. Each session gets a fresh Ubuntu 24.04 VM on x86_64 with common toolchains already there: Python, Node.js 20 to 22, Ruby, PHP, Java, Go, Rust, C and C++, Docker, PostgreSQL 16 and Redis. The cloud environments page↗ (opens in a new tab) gives the resource ceilings as roughly 4 vCPUs, 16 GB of RAM and 30 GB of disk.

A setup script is Bash that runs as a new session starts, before Claude Code launches. It must exit zero, or the session fails to start. If it finishes in about five minutes, the resulting filesystem is cached and later sessions skip it; the cache is rebuilt when you change the script or the allowed hosts, and after about seven days. Use it for things the image lacks, such as the .NET SDK. Put project steps that should also run on your laptop, such as npm install, in a SessionStart hook in the repository’s .claude/settings.json instead.

#!/bin/bash
apt update && apt install -y shellcheck
pip install -r requirements-dev.txt || true   # non-critical: do not block the session

Only what is committed travels. The repository’s CLAUDE.md, .claude/rules/, skills, agents and commands load in the cloud, and so do its .claude/settings.json and .mcp.json in a session with one repository. Your ~/.claude/CLAUDE.md, personal skills, MCP servers added at local or user scope, and interactive sign-ins such as AWS SSO do not. Environment variables and the setup script are readable by anyone who uses the environment, so keep secrets out of them.

Network access

• None: no outbound access through the session’s network.
• Trusted, the default: allowlisted domains only, meaning package registries such as npm, PyPI, RubyGems and crates.io, GitHub, and cloud SDKs.
• Full: any domain.
• Custom: your own list, one domain per line, optionally with the Trusted defaults added.

Some traffic bypasses the level you pick: GitHub through its proxy, MCP connectors you enable on the session (they travel through Anthropic’s servers), and Claude Code’s own calls to the Anthropic API, even at None. The documentation notes that this last channel means data can still leave the VM with network access switched off. With None, setup scripts and hooks that install packages fail.

Running several tasks at once

Each task gets its own session and its own branch, so parallel work needs no worktrees. From the browser, submit one task and start the next. From the terminal, each --cloud command creates a separate session, cloning your current branch from GitHub rather than your local checkout, so push first. A repository with no GitHub remote, or one the app is not installed on, is uploaded as a bundle instead, up to 100 MB. Parallel sessions share your account’s rate limits with all your other Claude use.

claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud "Update the API documentation"
claude -p "Also add a changelog entry" --cloud <session-id>   # follow-up to a running session

Pick the permission mode per session from the dropdown: Auto where your organisation allows it, Accept edits, or Plan. Cloud sessions offer neither Manual nor Bypass permissions. A large change works best planned locally in plan mode, with the plan committed and pushed, then executed in the cloud.

Reviewing and creating pull requests

Each session shows a diff indicator such as +42 -18. Open it to see the changes against the base branch, or choose Compare against for another branch, and leave inline comments that go to Claude with your next message. When the diff is right, Create PR opens a full pull request, a draft, or GitHub’s compose page with a generated title and description, as the getting started guide↗ (opens in a new tab) shows. Commits carry a Claude-Session trailer and the PR body links the session, so a reviewer can open the run that produced it.

With the GitHub App installed you can switch on auto-fix for a pull request: Claude watches it, and when a check fails or a reviewer comments, it pushes a fix if one is clear and asks you if the comment is ambiguous. Its replies on GitHub appear under your username, labelled as Claude Code. If a comment on your repository can trigger a deployment, through Atlantis or a workflow on issue_comment, the documentation advises reviewing that before turning auto-fix on.

Moving between the terminal and the cloud

• Terminal to cloud: claude --cloud "task" starts a new cloud session. From the CLI the handoff is one-way; you cannot push an existing terminal session to the cloud. The desktop app’s Continue in menu can.
• Cloud to terminal: claude --teleport opens a picker, claude --teleport <session-id> goes straight to one, and inside a running CLI session /teleport or /tp does the same. In /tasks, press t. On claude.ai/code, Open in, Terminal copies the command.
• Teleport needs a clean working tree (it offers to stash), a checkout of the same repository rather than a fork, the branch pushed, and the same claude.ai account. --resume does not list cloud sessions.
• After teleporting, the terminal has its own copy. New work there does not appear in the cloud session.

What it cannot do

• Push anywhere but GitHub. GitLab or Bitbucket code can be sent as a bundle, but results cannot be pushed back.
• Run terminal-only commands such as /plugin or /resume; /clear is replaced by starting a new session.
• Install plugins a repository enables in its settings, or load anything that lives only in your home folder.
• Reach your private network or local services from an Anthropic-hosted environment, or run jobs that need more than the VM’s memory. For those, use Remote Control on your own hardware or a self-hosted environment.
• Keep going indefinitely while idle. An idle session’s VM is reclaimed; reopening restores the conversation but not background work that was still running.
• Run at all if your organisation uses IP allowlisting, until Anthropic support exempts its hosted services.

Security

Each session runs in its own isolated VM, separate from your machine and from other sessions. Git credentials and signing keys stay outside the sandbox, and on Pro and Max plans API keys you add to an environment as credentials are attached by a proxy rather than exposed to the session. Sharing needs care: on Pro and Max, Public visibility lets any signed-in claude.ai user open the session, which may contain code and credentials from a private repository. Team and Enterprise accounts share with the team instead, with repository access checked by default.

One list for many sessions

Three cloud sessions running in parallel give you three transcripts in a sidebar, titled by their first message. A fenbs board keeps the list of what each one is for. Add fenbs as a connector on your Claude account, as the Claude integration describes, and enable it on the session: connector traffic goes through Anthropic, so it needs no change to the network level. If you commit fenbs to .mcp.json instead, the session calls it over its own network, so a Custom level has to allow fenbs.ai. Then start each task with its reference (“work on BUG-031 from the board; comment the PR link on it when you open it”), and the board’s history records what each session did, under the assistant’s name, next to what your terminal sessions did. The CLAUDE.md lines that make it routine are in a task-tracking workflow for Claude Code.