Claude Code on the Web: Cloud Sessions and Teleport

My first cloud session confidently reported that the file I had asked it to fix did not contain the function I described. It was right. The function was in my working copy, uncommitted, on my laptop — and the cloud VM had cloned the GitHub remote at my current branch, which knew nothing about it.

That is the single most important sentence about this feature and it is easy to skim past. This post covers what a cloud session actually starts from, the bundle fallback for repositories without a GitHub remote, teleporting a session back down and its four requirements, auto-fixing pull requests and the automation risk that comes with it, and the isolation model plus the organisation setting that breaks it entirely.

What a cloud session starts from

Every cloud session runs in a cloud environment — a saved configuration controlling network access, environment variables and setup scripts — and the same environments apply wherever you start one: the web, the terminal, routines, and the mobile and Desktop apps.

# Start a cloud session from the terminal.
claude --cloud "Fix the authentication bug in src/auth/login.ts"

# The cloud VM clones your current directory's GitHub REMOTE at
# your CURRENT BRANCH — not your local checkout. Push first if
# you have local commits, or they are simply not there.

# Each --cloud call is an independent session. Run several:
claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud "Update the API documentation"
claude --cloud "Refactor the logger to use structured output"

/tasks          # watch them all from the CLI

# Send a follow-up to a running session from ANY machine you
# are logged in on. Queues the message and exits.
claude -p "also update the changelog" --cloud <session-id>

# No GitHub remote? Claude Code bundles the local repository and
# uploads it: full history across all branches, plus uncommitted
# changes to TRACKED files. Untracked files are not included.
# Under 100 MB, and the session cannot push back to a remote.
CCR_FORCE_BUNDLE=1 claude --cloud "Run the tests and fix failures"

Teleport pulls, and nothing pushes

You can start a cloud session from the terminal and you can pull one back down, but you cannot send an existing terminal session up. The Desktop app has a continue-in menu that can, which is worth knowing if that direction matters to you.

# Pull a cloud session down into your terminal.
claude --teleport                  # interactive picker
claude --teleport <session-id>     # straight to one
/teleport                          # from inside a CLI session
/tp                                # the same, shorter
# Or from /tasks: select a session and press t

# --teleport is NOT --resume.
#   --resume   reopens a conversation from THIS machine's local
#              history, and does not list cloud sessions
#   --teleport pulls a cloud session AND its branch

# After teleporting, the terminal gets its OWN copy. New work
# stays local and does not appear in the cloud session on
# claude.ai or the mobile app. To keep steering from your phone,
# start /remote-control in the local session.

The detail that catches people is what teleport leaves behind. After teleporting, the terminal has its own copy of the session — new work stays local and does not appear in the cloud session on claude.ai or the mobile app. If you want to keep steering from your phone after pulling a session down, start Remote Control in the local session, which is a different mechanism entirely.

Teleport's four requirements

Teleport checks these before resuming, and each failure has a specific message rather than a generic one.

What teleport verifies:

Repositories without a GitHub remote

When you start a cloud session from a repository not connected to GitHub, Claude Code bundles the local repository and uploads it directly. The bundle includes full history across all branches plus uncommitted changes to tracked files — which is the one case where your uncommitted work does travel. Untracked files are not included, so add anything you want the session to see.

The limits are worth knowing before you rely on it. The directory must be a git repository with at least one commit, and the bundle must be under 100 MB — larger repositories fall back to bundling only the current branch, then to a single squashed snapshot, and fail only if that is still too large. A session created from a bundle cannot push back to a remote unless you also have GitHub authentication configured.

Auto-fixing pull requests

Claude can subscribe to GitHub activity on a pull request and respond to CI failures and review comments on its own. What it does depends on how clear the situation is:

• A clear fix that does not conflict with earlier instructions gets made, pushed and explained in the session.
• An ambiguous comment, or anything architecturally significant, gets a question to you instead of an action.
• A duplicate or no-action event is noted in the session and skipped. Note that GitHub emits no webhook when the base branch advances into a conflict, so auto-fix cannot react to merge conflicts — open the session and ask for a rebase.

How a session is isolated

In Anthropic-hosted environments the separation runs through several layers, and one of them is worth stating precisely because it is easy to overstate:

• Each session runs in an isolated, Anthropic-managed virtual machine.
• Network access is limited by default and can be disabled — but even with it disabled, Claude Code still reaches the Anthropic API, which may allow data to leave the VM.
• Sensitive credentials such as git credentials and signing keys are never inside the sandbox; authentication goes through a secure proxy using scoped credentials.
• In a self-hosted environment, all of that becomes your deployment's responsibility instead — isolation, egress and git credentials are yours to configure.

The constraints that decide whether you can use it

Four limitations are worth checking before building a workflow on this. Rate limits are shared with all other Claude usage on your account, so parallel tasks consume proportionately more — there is no separate compute charge for the VM, but there is no separate budget either. Repository cloning and pull-request creation require GitHub; GitLab and Bitbucket repositories can be sent as a bundle but cannot push results back.

The fourth is the one that stops organisations dead. Anthropic-hosted cloud sessions call the API from Anthropic-managed infrastructure rather than your network, so if your organisation has IP allowlisting enabled, every one of them fails with an authentication error. The same applies to code review and to routines on Anthropic-hosted environments. A routine routed to a self-hosted environment calls from your own network and is unaffected — otherwise it is a support conversation to exempt Anthropic-hosted services.

The mental correction that makes this feature work is that a cloud session starts from your remote, not your desk. Push before you dispatch, plan locally where steering is cheap, and let the cloud do the part that benefits from running unattended. Everything else here is detail — but that one sentence is the difference between a session that does what you asked and a session that correctly reports your code does not contain something you have not pushed yet.