
Claude Code cloud sessions: a field guide to running agents on fresh VMs

Cloud sessions give Claude Code a machine of its own. Instead of depending on your laptop for the working tree, credentials, and uptime, each task runs on a fresh virtual machine with your repository cloned onto a new branch and the environment already set up. You can start a session from claude.ai/code, the Claude mobile app, the Desktop app, your terminal, or Slack, and follow it from the browser, mobile, or Desktop. Cloud sessions are included with Pro, Max, Team, and Enterprise plans at no separate compute charge, and they draw on the same usage limits as regular Claude Code. Depending on the plan, an organization owner may need to enable them first. Existing individual Pro and Max subscribers can claim a one-time bonus credit: $100 on Pro and $250 on Max, claimable by October 7 at claude.ai/code/claim-credit or with /claim-credit, expiring November 4 and not eligible for Projects or Routines.
The guide reports four real cloud sessions against a fictional Node API called tidepool. Three were started within 16 seconds of each other, one per problem, and ran for 61, 65, and 72 seconds; all three finished 87 seconds after the first start. The flaky-test session found a race in TtlCache.get: the cache stored a value only after the loader finished, so a second get for the same key during a load called the loader again. It changed the cache to store the in-flight promise, dropped the entry when a load failed, and ran npm test 40 times in a row with zero failures. The docs session started the server, curled every endpoint, and found five ways the documentation was wrong, including a days parameter the code ignores and heights given in feet when they are metres, plus a caveat about a malformed from= value returning an empty list with a 200. The logger session wrote a JSON logger and five tests, hit the same cache race, proposed the same fix, left the cache alone because it was outside its task, and reported that the suite wasn’t clean. The isolation means parallel sessions do not see each other’s fixes, so the advice is to split tasks along file boundaries, merge branches in a sensible order, and expect one session to surface a problem another session is already fixing.
Under the hood, everything the agent can touch sits inside the VM. Your GitHub token never enters it: a proxy holds the token and the session gets a short-lived credential that can push only to its own working branch. The repository’s CLAUDE.md, rules, skills, agents, and commands travel with the repo, but your personal ~/.claude stays on your laptop. Idle VMs are reclaimed, and reopening a session gives you a fresh VM with the conversation restored, so committing work you care about is important. Local sessions still make sense for tasks that need local databases, VPN-reachable services, GPUs, simulators, hardware, tight visual loops, or Zero Data Retention organizations. Remote control keeps the session on your machine while you steer it from a phone or browser, and self-hosted environments, in beta for Team and Enterprise, run cloud sessions on your organization’s own infrastructure.
The guide’s seven workflows cover parallel backlog clearing, proving fixes with repeated test runs, using plan mode at your desk and then executing in the cloud, finishing in your terminal with claude –teleport, checking in from your phone, handing CI failures and review comments to Claude via the GitHub App’s Auto-fix, starting work with routines and triggers, and running code you don’t fully trust in a disposable VM with a narrowed network. Even with network access set to None, requests still go to the Anthropic API and the session can still push to its own branch; all outbound traffic passes through a proxy that logs hostnames.
GitHub connection issues are the most likely setup failure, because cloud sessions need two separate permissions: signing in with GitHub tells Claude who you are, and installing the Claude GitHub App sets which private repositories Claude can see. Public repositories work with sign-in alone; private repositories need the App on the account or organization that owns them. The browser connection path at claude.ai/connect-github is recommended, /web-setup sends a gh token from your terminal, and a one-off session with no GitHub remote uploads a repository bundle instead of cloning. Team and Enterprise owners need to enable the GitHub connector, allow cloud sessions in admin settings, install the App, and decide about Quick setup; a troubleshooting table covers missing private repos, SAML authorization, IP allowlists, and org ownership errors.
Environment setup is what lets sessions check their own work. The Default environment uses Trusted network access, no variables, and no setup script, which is enough for most JavaScript, Python, Go, and Rust repositories. A setup script runs as root before Claude Code starts, must exit 0, should finish within about five minutes, and lands in a cached snapshot. Project steps like npm install belong in a SessionStart hook in the repository’s .claude/settings.json; services must be started per session; environment variables are visible to anyone who uses the environment; and commands must live in CLAUDE.md because personal configuration never reaches the cloud VM. Habits that pay off: one task per session, ask for evidence, push before claude –cloud, commit as you go, review in the diff view, steer with queued messages, share sessions on Team and Enterprise, and watch your limits, since parallel sessions consume plan usage in parallel. The cloud VM has about 4 vCPUs, 16 GB of RAM, and 30 GB of disk; heavy installs should go in a setup script. GitLab and Bitbucket work with a bundle upload but can’t receive pushes back, and sessions don’t know about each other’s branches, so merge one branch and send follow-up instructions to the next session.


