Claude Code sessions keep running after you close the laptop

On September 23, Anthropic took Claude Code on the web out of research preview, renamed it cloud sessions and made it generally available. A cloud session is a Claude Code session that runs on a VM Anthropic manages, or in your organization’s self-hosted environment if your org routes it there. It keeps working after you close the laptop, and you can check on it or steer it from any device.

The Claude Code documentation from Claude lists five ways to start one: claude.ai/code in the browser, the Code tab in the Claude mobile app, the Cloud option in the Desktop app, claude --cloud in the terminal, and routines, which are scheduled or triggered runs that each get their own cloud session. When one body of work needs many sessions, a project starts them and keeps track of them, and that is the mechanism behind the parallel threads that come back as ordinary merge conflicts. Every session uses a cloud environment, a saved configuration that sets network access, environment variables and setup scripts. The same environments apply wherever you start the session.

What actually reaches the VM

claude --cloud clones your current directory’s GitHub remote at your current branch. It does not take your local checkout, so local commits have to be pushed first. Each invocation opens a separate session for a single repository, and several can run at the same time. The old --remote spelling still works as a deprecated alias. While the container boots, the CLI shows a checklist of setup steps, such as the clone and your setup script, and holds anything you type until the session is ready.

Without a usable remote, Claude Code uploads the repository instead. That covers a repo with no git remote at all, and a github.com repo the Claude GitHub App isn’t installed on, even if you connected GitHub through /web-setup. The bundle holds the full history across all branches plus uncommitted changes to tracked files. Untracked files stay behind unless you git add them. The limit is 100 MB. Above it, Claude Code falls back to bundling only the current branch, then to a single squashed snapshot of the working tree, and fails if that is still too large. Setting CCR_FORCE_BUNDLE=1 forces a bundle even when a clone would work. That is also how a GitLab or Bitbucket repository gets into a session, but the session cannot push results back to that remote.

Secrets get a filter, and it covers less than it seems to. On macOS, Linux and WSL, Claude Code leaves out uncommitted changes to files named like credentials: .env files, Terraform *.tfvars, and keys such as id_rsa and *.pem. It also names the files it skipped, and the session gets the committed version of each, or no file if none was committed. In a linked worktree, a submodule or a similar layout, those changes are uploaded with everything else, and Claude Code names the files it uploads.

A running session also accepts messages from any machine where you are logged in. claude -p "your message" --cloud <session-id> queues one message and exits without waiting for a reply. The CLI sends no local session state, so the command works from a CI script, and --output-format json returns {ok, session_id, url} for scripts to parse.

Teleport makes a copy

claude --teleport brings a cloud session back down to the terminal. It checks that you are in the right repository, fetches and checks out the session’s branch, and loads the full conversation history. What you get locally is a copy. New work in the terminal stays local and never shows up in the cloud session on claude.ai or in the mobile app. To keep steering from your phone after that, you start /remote-control in the local session.

Teleport has four requirements: a clean working tree (it offers to stash), a checkout of the same repository and not a fork, a session branch that has been pushed, and the same claude.ai account. Sign-in also matters. Teleport and --cloud need claude.ai subscription authentication, so an API key gets you Unable to get organization UUID. Cloud sessions are not available at all if Claude Code is set up for Amazon Bedrock or Google Vertex AI, because they run on Anthropic’s infrastructure and require an Anthropic account.

Auto-fix on pull requests

Claude can also watch a pull request. Running /autofix-pr on the PR’s branch finds the open PR with gh, spawns a cloud session and turns on monitoring in one step. When a check fails or a reviewer comments, Claude investigates and pushes a fix when it is confident the fix is clear and doesn’t conflict with earlier instructions. When a comment is ambiguous or touches something architecturally significant, it asks you first. Merge conflicts are outside its reach, because GitHub sends no webhook when the base branch moves and creates one. In that case you open the session and ask for a rebase. Replies Claude posts in review threads appear under your GitHub username, each labeled as coming from Claude Code.

Isolation, sharing and the meter

In Anthropic-hosted environments, git credentials and signing keys stay outside the sandbox, and a proxy authenticates on the session’s behalf with scoped credentials. Network access is limited by default and can be switched off. The docs add one caveat: even with networking disabled, Claude Code can still reach the Anthropic API, “which may allow data to exit the VM.” On self-hosted environments, isolation and egress control are your deployment’s job.

Sharing depends on the plan. Team and Enterprise sessions can be Private or Team, with repository access checks on by default. Pro and Max sessions can be Private or Public, and Public means any logged-in claude.ai user can open the link. Repository access verification is off by default there, and the docs warn that sessions may contain code and credentials from private repositories.

The VM itself carries no separate compute charge. Cloud sessions draw on the same rate limits as all your other Claude and Claude Code usage, so parallel tasks use them up proportionately. For the launch, Pro subscribers got $100 and Max subscribers $250 in one-time credits that can only be spent on cloud sessions. Idle sessions expire and their VM is reclaimed. Reopening one restores the conversation but not any subagents or shell commands that were still running. A session waiting for you to approve an MCP tool call also counts as idle and can expire during the wait.

One limit can stop everything. Hosted sessions call the Anthropic API from Anthropic’s infrastructure, not from your network, so an organization with IP allowlisting turned on will see every Anthropic-hosted cloud session fail with an authentication error. The fix is to contact Anthropic support and have Anthropic-hosted services exempted from the allowlist.