Claude Code sessions keep running after you close the laptop

If you start a task with claude --cloud and then close your laptop, the task keeps going on a virtual machine run by Anthropic, and you can check on it from your phone. Claude's documentation for Claude Code on the web explains how it works, including the part that costs you: the VM itself is free, but it does not come with its own rate limits.

At a glance

• A Claude Code cloud session runs on Anthropic-managed infrastructure or on an organization's self-hosted environment, and you can start one from the browser, the Claude mobile app, the Desktop app, the terminal or a routine.
• The VM clones your branch from the GitHub remote, not from your local checkout. If there is no usable remote, Claude Code uploads a bundle under 100 MB instead, and claude --teleport pulls the branch and history back.
• There is no separate compute charge for the cloud VM, but cloud sessions share rate limits with all your other Claude usage, and parallel tasks use up those limits proportionately.

If you have not been following along: according to ScriptByAI, Claude Code entered research preview on February 24, 2025, and became generally available on May 22, 2025. The same site dates the steps toward moving sessions between devices. VS Code sessions could connect to a browser or phone from May 13, 2026, and Team and Enterprise users could run remote sessions on their own infrastructure from Aug. 7, 2026. ScriptByAI also lists a Projects beta on Sep. 17, 2026, in which a coordinator hands goals to parallel cloud sessions.

claude --cloud clones your GitHub branch, not the files on your disk

From the terminal, it takes one flag. claude --cloud creates a new session on claude.ai, and the cloud VM clones your current directory's GitHub remote at your current branch. The VM never sees local commits you have not pushed, so push first. The flag handles one repository at a time, and the older --remote spelling still works as a deprecated alias.

While the container starts, the CLI shows a live checklist of setup steps, such as cloning and running your setup script. Anything you type during that time is queued until the session is ready. Each --cloud command starts its own independent session, so several tasks can run at once. For complex work, the documentation suggests planning locally in plan mode, committing and pushing the plan, and then sending the execution to the cloud.

Without a usable remote, Claude Code uploads a bundle under 100 MB

If the repository has no git remote, or is on github.com without the Claude GitHub App installed, Claude Code bundles it and uploads it directly. The bundle includes the full history across all branches plus uncommitted changes to tracked files. On macOS, Linux and WSL, it leaves out uncommitted changes to .env files, Terraform *.tfvars files and keys such as id_rsa and *.pem, and tells you which files it skipped.

The bundle must be under 100 MB. If a repository is larger, Claude Code first tries bundling only the current branch, then a single squashed snapshot of the working tree, and fails if that is still too big. Untracked files are not included. Setting CCR_FORCE_BUNDLE=1 sends GitLab or Bitbucket code this way, but the session cannot push results back to that remote.

--teleport pulls a cloud session into your terminal as a separate copy

To go the other way, run claude --teleport. On its own it opens a session picker. With a session ID, it resumes that session directly. Before it does, Claude Code checks four things: you are in a checkout of the same repository (not a fork), your working tree is clean, the session's branch has been pushed, and you are signed in to the same claude.ai account. It then checks out the branch and loads the full conversation history.

The terminal gets its own copy. New work there stays local and does not appear on claude.ai or in the mobile app. To keep steering from your phone after that, start /remote-control in the local session. Teleport is also different from --resume, which only reopens conversations saved on this machine. Separately, claude -p "message" --cloud <session-id> sends one message to a running session from any logged-in machine.

Auto-fix answers CI failures and review comments under your GitHub name

Claude can also watch a pull request for you. With auto-fix on, it receives GitHub events for the PR. When a check fails or a reviewer comments, it investigates and pushes a fix if the fix is clear. It asks you first about ambiguous or architecturally significant requests, and it notes duplicate events and moves on. You turn auto-fix on from the CI status bar, with /autofix-pr in the terminal, or by asking in the mobile app.

Replies to review threads are posted under your GitHub username, and each one is labeled as written by Claude Code. The documentation states one gap plainly: GitHub sends no webhook when the base branch moves and creates a merge conflict, so auto-fix cannot react to conflicts. To fix one, you open the session and ask Claude to rebase.

Git credentials stay outside the sandbox, and a proxy signs requests

Each session runs in an isolated, Anthropic-managed VM, separate from your machine and from other sessions. In Anthropic-hosted environments, git credentials and signing keys never enter the sandbox. Instead, a proxy authenticates on the session's behalf with scoped credentials. It works like a valet key: the attendant can drive the car around the block but cannot open the glovebox.

On Pro and Max plans, API keys you add to an environment are kept outside the sandbox the same way. Team and Enterprise plans do not have this yet. Network access is limited by default and can be turned off, but even then Claude Code can still reach the Anthropic API, which the documentation says may let data leave the VM. In self-hosted environments, isolation and outbound traffic are your deployment's responsibility.

The limits are in the fine print. If your organization uses IP allowlisting, every Anthropic-hosted session fails with an authentication error until Anthropic support grants an exemption. And when a VM is reclaimed for inactivity, any subagents or shell commands still running are not restored. In our view, the sharing default on Pro and Max is the weak spot: a Public session is visible to any logged-in claude.ai user and may contain private code and credentials, yet repository access verification is off by default.

How long an idle VM survives. The documentation says sessions stop after a period of inactivity, and that waiting for an MCP approval counts as inactive, but it gives no time limit. It also does not say how many parallel sessions a plan's rate limits can support before they run out. Until Anthropic publishes those numbers, you will only learn how far claude --cloud goes on your plan by using it.