When you run Claude Code in a terminal on your personal computer, the workflow is closely tied to that laptop. Two sessions working on the same repository can interfere with each other's files, and test servers can fail when they compete for the same network port(for example, both trying to use port 3000). The sessions share an environment with your SSH keys and cloud credentials. Work cannot keep progressing while the computer sleeps, and losing connectivity interrupts steps that need the model or a remote service.

Claude Code cloud sessions(Cloud Sessions) move that work to the cloud. You submit a task, and the system starts a fresh, isolated virtual machine(VM: a virtual computer allocated in the cloud, separate from other tasks), clones the repository, and works automatically on a dedicated new branch. At a stopping point, it pushes the branch containing its changes. You can then turn those changes into a Pull Request(PR: a request for the team to review and merge a set of code changes).

This capability is included in paid Pro, Max, and Team subscriptions, as well as Enterprise subscriptions with Premium or Chat + Claude Code seats. There is no additional cloud-compute fee; tasks count toward your account's existing usage allowance.

Quick decision: which tasks belong in the cloud, and which should stay local?

Cloud sessions do not replace the local terminal entirely. Understanding their boundaries helps you assign everyday development tasks appropriately:

Situations that are better kept local

• Private data or a specific network: the task needs a test database available only in local Docker, or a service that requires your company's VPN.
• Physical hardware: it needs your local GPU, an attached development board, or a mobile simulator running on your computer.
• Frequent visual iteration: you need immediate browser feedback after each small style or interaction change.
• Strict compliance requirements: your organization enables Zero Data Retention(ZDR; cloud sessions are automatically disabled under this policy).

If the task needs your local environment but you want to leave your desk, use Remote Control(computation stays on your computer; your phone or browser sends instructions and displays progress). Team and Enterprise organizations can also consider Self-hosted Environments(a commercial-plan Beta feature that runs sessions on infrastructure your organization operates). When those constraints do not apply, cloud sessions can free up substantial resources on your computer.

Step 1: connect your GitHub repository in the browser

For private code, start by distinguishing two separate sets of GitHub permissions:

1. Sign in to Claude with GitHub: establish your user identity, with basic credentials that can read public repositories.
2. Install the Claude GitHub App: explicitly authorize which private repositories Claude may read and write, and enable subsequent automatic fixes and event notifications.

All four connection methods can read public repositories. Their private-repository access and automation support differ:

Here, GitHub automation means Auto-fix, GitHub event triggers, and Projects. An ordinary scheduled Routine does not universally require the App.

Route A: connect through the browser (recommended for your first session)

You can complete this entire route in a modern browser. You do not need Node.js, Git, or any command-line tools installed locally.

Account and permission prerequisites:

• Eligible account and seat: cloud sessions require a paid claude.ai account: Pro, Max, Team, or Enterprise with an assigned Premium or Chat + Claude Code seat. A separate API key obtained through Anthropic Console, or a third-party provider such as AWS Bedrock or Google Cloud Vertex AI, does not support cloud sessions.
• Organization settings: for Team or Enterprise, an organization Owner must first enable two features in the admin settings: the GitHub Connector at claude.ai/admin-settings/connectors, and Cloud sessions at claude.ai/admin-settings/claude-code. If the connector is disabled, you may see “GitHub access is required for Claude Code cloud sessions.”

Four steps to connect in the browser:

1. Sign in to Claude: open claude.ai/code and sign in with the eligible paid claude.ai account above. If GitHub is not linked yet, the page guides you through connecting it. You can also go directly to claude.ai/connect-github.
2. Connect your GitHub identity: click Connect to GitHub in the middle of the interface. You will be redirected to GitHub's authorization page to confirm your personal identity:

3. Install the Claude GitHub App: after signing in, follow the prompt to install the Claude GitHub App. Install it on your personal account or the target organization, then select All repositories or Only select repositories for repository access:

4. Check the signs of a successful connection: after authorization, you return automatically to claude.ai/code. Look for these observable signs:
   • The repository selector beside the input can find and select the private repositories you authorized.
   • The environment selector above the input offers the Default environment.

Troubleshooting common browser connection problems

If the authorization flow does not return correctly, or the repository list is empty, check these official troubleshooting points:

• Problem 1: a private repository is completely missing from the selector
  Check and fix: the App is not installed on the account or organization that owns the repository, or that repository was omitted during installation. In the GitHub personal or organization settings, open Settings > Applications > Installed GitHub Apps, find Claude, and add the repository to its authorized list.
  
• Problem 2: a message says an organization Owner is required to connect
  Check and fix: the organization has membership protection or permission-review rules. An organization Owner needs to approve the request in the organization's GitHub App settings, and enable IP allow list inheritance for the installed App, or authorize Claude through its SAML single sign-on settings. For Team or Enterprise, the Owner must also enable the GitHub Connector at claude.ai/admin-settings/connectors first.
  
• Problem 3: authorization succeeds, but the organization's repositories disappear
  Check and fix: the organization uses SAML single sign-on(SSO), and you skipped it in the GitHub authorization dialog's “Single sign-on to your organizations” list. Open Applications > Authorized OAuth Apps in your personal GitHub settings, find Claude, click Authorize beside the organization, and sign in again.
• Problem 4: all sessions report “Authentication Error”
  Check and fix: your organization has configured an enterprise IP allowlist in the Claude console. Ask an administrator to exempt Anthropic's cloud-infrastructure service IPs by adding them to the allowlist.

Optional: first-time local CLI installation (for terminal users)

If you want to synchronize credentials or launch tasks from your local command line, install Claude Code using the official command in your system terminal first. Browser-only readers can skip this section:

• macOS, Linux, and WSL:

  curl -fsSL https://claude.ai/install.sh | bash
  

• Windows PowerShell:

  irm https://claude.ai/install.ps1 | iex
  

After installation, open a new terminal window and run claude --version. If it prints a version number, installation succeeded and your PATH is working.
Shell note: Windows users must run the command in PowerShell. If you see 'irm' is not recognized, you are using the older CMD shell.

Route B: synchronize existing gh credentials from the terminal (for CLI users)

If you have already installed and configured GitHub's official gh CLI locally, you can quickly synchronize its credentials. Distinguish system-terminal commands from slash commands inside an interactive Claude session:

1. In your system terminal, make sure you are signed in to GitHub:

   gh auth login
   

2. Enter claude in your system terminal to start an interactive Claude Code session:

   claude
   

3. At the Claude Code prompt, check your login credentials:
   • If you are not signed in yet, enter this slash command:

     /login
     

   • Enter /status and confirm that Login method shows a claude.ai subscription account. An API-key login does not support cloud features.
4. At the Claude Code prompt, enter the credential-sync command(for Team/Enterprise, an Owner must first enable Quick setup in the admin settings):

   /web-setup
   

5. Explicitly confirm credential upload: Claude Code calls gh auth token to read your local token, then asks you to confirm uploading and linking it to your Claude account. This is an explicit interaction, not a silent upload.
6. After you agree, the token is transmitted with encryption and linked to your cloud account. The terminal prints Connected as <your-GitHub-username> and automatically opens claude.ai/code in the browser.
7. Missing workflow permissions: if the terminal warns that the workflow scope is missing, return to the system terminal and run:

   gh auth refresh -s workflow
   

   After granting the scope, return to Claude Code and run /web-setup again to upload the token anew. The permission change will not take effect otherwise.
8. What disconnecting does: removing the GitHub connection at claude.ai/customize/connectors deletes only the credentials stored by Anthropic. It does not sign out your local gh CLI or invalidate its login. To revoke the token entirely, revoke GitHub CLI authorization in your personal GitHub settings under Applications > Authorized OAuth Apps.

Route C: upload a local project with Bundle when there is no remote repository

For a new local project that has not been pushed to GitHub, or a repository without the App installed, run this in your local terminal:

claude --cloud "Task description"

The system bundles your local code and uploads it to the cloud VM. If you already have a remote repository but want to force local bundling, set this variable explicitly in Bash/Zsh:

CCR_FORCE_BUNDLE=1 claude --cloud "Task description"

Check these prerequisites before bundling:

• The local directory must be a valid Git repository with at least one Git commit.
• The bundle limit is 100MB. If it is too large, bundling falls back to the current branch only or a single squashed snapshot; if that is still too large, upload is rejected.
• Untracked files are never bundled. Run git add to stage any required files before launching.
• Platform differences for sensitive files: on macOS, Linux, and WSL, Claude Code excludes uncommitted changes to sensitive files, including .env, *.tfvars, id_rsa, *.pem, and files managed by Git LFS. It prints Left on this machine:; the cloud retains only those files' committed historical versions. In a native Windows terminal, uncommitted changes to tracked files are uploaded as-is.
• If the linked account lacks write access to the remote repository, this session cannot push its changes to GitHub. Direct branch pushes to GitLab or Bitbucket are not supported.

Step 2: configure the cloud environment and project instructions

Default already includes tools such as Node.js, Python, Go, Rust, Git, and Docker, and uses Trusted network access. For your first session, select Default and skip ahead to the third step. Add a Setup script, SessionStart hook, and CLAUDE.md when your project needs extra tools, dependencies, or verification commands.

1. Find the environment selector and create Default

On claude.ai/code, the row above the input shows the currently selected environment(by default, a Default button with a cloud icon):

• Pro and Max: a Default environment is created automatically when you first enter.
• Team and Enterprise: if an administrator has not enabled Quick setup, you will see “Create your first cloud environment.” Keep the Default name and Trusted network access, then click Create & finish.

If your project needs special system tools, environment variables, or network access, click the icon, choose Cloud, and select Add cloud environment. To edit an existing environment, hover over it and click its gear icon:

2. Key environment settings, saving, and verification

When creating or editing an environment, configure these fields and complete the save process:

• Name: use a recognizable name, such as tidepool-env.
• Network access:
  • Trusted (recommended default): allows common package managers such as npm, PyPI, RubyGems, and crates.io, GitHub domains, and major cloud-service SDKs.
  • None (strictest network isolation): blocks all ordinary outbound session requests. Model communication between the VM and the Anthropic API, and Git pushes to its own working branch, remain allowed. None therefore does not mean physically offline.
  • Custom: enter allowed domains one per line, with wildcards such as *.internal.example.com. Changes synchronize to the current session in about 1 minute.
  • Full: unrestricted internet access.
• Environment Variables: enter plain .env text, such as LOG_LEVEL=debug. Every collaborator who can use the environment can see these plaintext variables. Do not paste private keys here.
• API Credentials (Pro and Max only): to call a private third-party API, save the environment and reopen its edit dialog. In API credentials, click Add credential. The cloud proxy dynamically injects headers such as a Bearer Token for a specified domain. The secret stays outside the VM and cannot be inspected from its terminal, environment variables, or code.
• Save and check the selected environment: click Create environment for a new environment, or Save changes for an existing one. Then check the name beside the cloud icon above the main input to confirm that your new environment is selected.

3. Separate system-level Setup from project-level SessionStart hooks

The key distinction is between the VM's operating-system layer and the repository's code-dependency layer:

Step A: write the VM Setup script (install system software only as needed)

If your project depends on a system CLI such as shellcheck, enter a plain Bash script into Setup script in the environment dialog. It is saved in the cloud environment, not a local file. Add set -e so an installation failure exits immediately; the exit code must be 0. If the script completes successfully within about 5 minutes, the system caches the prepared filesystem as a snapshot. New sessions then start from those installed files. The cache is rebuilt when you change the script or allowed hosts, or when it expires after about seven days:

#!/bin/bash
set -e

# Install Linux system tools only if the project needs them (shellcheck is an example, not universally required)
apt-get update
apt-get install -y shellcheck

A VM disk snapshot caches files, not running processes in memory. Background database services such as service postgresql start or service redis-server start will therefore be stopped in a new session even if the Setup script started them. Start them with a session hook or ask the Agent to do it.

Step B: write a project-level SessionStart hook (Node.js example)

Store code-level dependency setup, such as npm install, in the local repository's configuration. Create or edit .claude/settings.json in the repository root.

Merge existing settings: if .claude/settings.json already exists, do not overwrite the entire file or an entire key. If it already contains the "hooks" key, add or merge the SessionStart array entries within the existing "hooks" object, alongside other hook events. Preserve the team's existing permission rules and other settings.

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

Next, create scripts/install_pkgs.sh in your local repository. This script is for a Node.js project. It checks CLAUDE_CODE_REMOTE to identify the cloud container, avoiding a repeated install every time you start a local session. set -e prevents errors from being hidden:

#!/bin/bash
set -e

# Exit successfully outside a cloud VM so local development is unaffected
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

# Enter the project root and install Node project dependencies
cd "$CLAUDE_PROJECT_DIR"
npm install

Step C: put project instructions in CLAUDE.md

Your personal computer's ~/.claude configuration is not uploaded to the cloud. Put the project instructions your team wants cloud sessions to use in the repository. Create and commit CLAUDE.md in its root.

Check the commands first: npm start, npm test, and npm run lint here are Node.js examples. Check the scripts field in your actual package.json before adding them. Delete the lint line if no lint script exists. If the development server does not use port 3000, use its actual port. Do not assume every project provides lint or listens on port 3000.

# Project development and verification instructions

## Common commands
- Install dependencies: `npm install`
- Start the service: `npm start` (check package.json and use the actual port)
- Run tests: `npm test` (check the actual test command in package.json)
- Check code: `npm run lint` (delete this line if package.json has no such script)

## Acceptance and commit process
1. Identify the root cause before fixing code; do not change test assertions to conceal errors.
2. After each logic change, run the relevant automated tests and confirm the full suite passes.
3. Use semantic commit prefixes such as `fix:`, `feat:`, `docs:`, and `refactor:`.

Step D: commit the three local files and check that they take effect

All three files above are local repository files: .claude/settings.json, scripts/install_pkgs.sh, and CLAUDE.md. Commit and push them from your local terminal:

git add .claude/settings.json scripts/install_pkgs.sh CLAUDE.md
git commit -m "build: 配置云端环境安装钩子与项目规范"
git push

Observable verification signs:

1. Run git status to confirm there are no uncommitted changes, and confirm your branch is synchronized with the remote.
2. Start a simple new cloud session at claude.ai/code. In its initialization log or preparation steps, check that the SessionStart hook ran and npm install succeeded. Then ask the Agent to run the tests specified in CLAUDE.md and report the actual output.

Step 3: submit a task with a clear scope and verification method

1. Submit your first task on the web

1. Open claude.ai/code and sign in with an enabled account.
2. Click the repository selector (Select repo) beside the input and select an authorized repository. Click the Branch selector beside its name to choose the starting branch. This is the default branch unless you choose a specific feature branch.
3. Check the Permission Mode dropdown beside the input:
   • Auto: a classifier reviews the Agent's actions; availability depends on organization settings and the selected model.
   • Accept edits: file changes and branch pushes proceed automatically without step-by-step confirmation.
   • Plan: analyze and produce a plan first; files are changed only after you approve the plan.
   • (Cloud sessions do not offer the per-command Manual mode or the unrestricted Bypass mode.)
4. Enter the task and press Enter to submit. You can then close the browser or turn off your phone's screen; the VM keeps working in the background.

Start with a small task to learn the “submit → read results → inspect Diff” flow:

Check whether the README's installation and testing instructions match the current repository code.
Read package.json and the relevant scripts first, then run the installation and test commands that actually exist.
Fix documentation inconsistencies only; do not change application code.
Report what you checked, the actual commands and their output, and anything you could not verify.
When finished, commit and push to this session's working branch so I can review the Diff.

You can also prefill a new session with URL parameters. Apply standard URL encoding to every parameter value so non-ASCII text or special characters are parsed correctly. This can be useful for bookmarks or issue-tracker integration:

https://claude.ai/code?prompt=Fix%20flaky%20auth%20tests&repositories=acme-labs%2Ftidepool&environment=Default

2. Launch a task from the terminal with claude --cloud

If you prefer to launch tasks from the CLI, follow these steps:

1. Enter the project directory: run cd /path/to/your-repo in your system terminal to enter the project root.
2. Check the remote and workspace: run git status to confirm the working tree is clean, and git remote -v to confirm the correct GitHub remote.
3. Push local commits first: the cloud VM clones the current branch directly from the GitHub remote. Local unpushed commits do not reach the cloud. Run git push before launching. For a local project without a remote, use Route C's Bundle mode instead.
4. Launch the cloud task:

   claude --cloud "Task description and executable verification commands"
   

5. Find the session's web link: the CLI displays preparation steps such as cloning and Setup execution. When preparation is complete, it prints the session's web URL, such as https://claude.ai/code/session_01ABC.... Open it in a browser or use the Claude mobile app to follow progress.

3. A task template you can copy

Give the cloud session both its goal and its completion criteria. Explain the symptoms, set the scope, and specify executable commands that will verify completion.

Replace the example: auth.spec.ts is a sample filename. Replace it with your project's actual target file and symptoms. For a first trial, you can instead choose a low-risk task such as updating README deployment instructions and checking links. Do not copy a sample application filename blindly.

Copy and adapt this task template:

[Goal]
Fix an intermittently failing authentication-module test (sample file: auth.spec.ts).

[Technical requirements and investigation]
1. Inspect the existing test scripts in package.json, the target test file, and its implementation. Do not assume the root cause is a concurrency race; analyze the actual code.
2. Do not conceal errors by changing test assertions or deleting test cases. Keep changes strictly within scope; do not modify unrelated application files.
3. Preserve backward compatibility for existing public interfaces and function inputs and outputs.

[Repeated verification]
Run this counting loop in the cloud Bash terminal (replace npm test with the actual test command in package.json):
fails=0; for i in $(seq 1 30); do npm test >/dev/null 2>&1 || fails=$((fails+1)); done; echo "runs=30 fails=$fails"
Require 0 failures across 30 consecutive runs. If failures remain, report their causes and the failing checks honestly. Zero failures in 30 runs means the problem did not reproduce in that verification period; do not claim this eliminates every possible risk.

[Deliverables]
- Report the actual root cause you identified and the files changed.
- Report the verification command and terminal output (runs=30 fails=0, or the specific failed checks).
- Commit automatically and push to the claude/ working branch.

4. Add instructions and follow progress asynchronously

• Add instructions at any time: while the cloud session runs, you can add clarifications in the web input. New messages are queued automatically. You can remove a queued message if you made a mistake.
• Add instructions remotely from the terminal: in a system terminal signed in to the same account, use -p to add a message. Obtain the session ID from the session_... portion of its URL or the terminal output:

  SESSION_ID="Paste the actual session ID here"
  claude -p "Rebase the branch onto main, resolve conflicts, and run the project tests again" --cloud "$SESSION_ID"
  

Step 4: check changes and tests, then handle parallel branches

When a session ends, check what it actually changed and which tests it ran before deciding to merge. A completion indicator means the task stopped; verify test results separately in its record.

Open the Diff, review it, and send feedback to the session

On claude.ai/code, follow these five steps:

1. Read the session summary and check commands and failures:
   • Do not stop at the completed status. Read the Agent's closing summary and check the Bash commands it actually ran.
   • Look for any reported failing tests. In the experiment below, for example, the logging task completed its own implementation but explicitly reported that the cache test still failed intermittently.
2. Click the additions/deletions indicator to open Diff:
   • The interface shows the branch's additions and deletions, such as +42 -18. Click that indicator to open the code comparison.
   • The changed-file list is on the left and the code comparison on the right. Use Compare against at the top to change the comparison branch. It defaults to the working branch's starting base; you can choose main instead.
3. Check the scope file by file:
   • Open each file and confirm every change falls within the allowed task scope.
   • Check for arbitrary changes to public interfaces, unrelated configuration, or test assertions.
4. Write inline comments, then send them with a message:
   • Click a specific code line in the Diff, enter feedback, and press Enter. For example: At src/cache.js:35, explicitly remove the pending Promise from the map after catching an error so a stale entry does not remain cached.
   • Important interaction: pressing Enter queues the comment locally; it has not been sent to the Agent yet. Return to the conversation input and send a main message, such as I added inline feedback about cache cleanup in the Diff. Update the code accordingly and rerun verification. The queued inline comments are then sent together with that message.
5. Have the Agent verify again:
   • After receiving the comments, the Agent updates the code, reruns cloud tests, and pushes the branch again for another review.

Parallel experiment: why a “Done” indicator is not enough

To show the value and limitations of isolated cloud machines, Addy Osmani ran real sessions against tidepool, a fictional teaching project(a simulated tide-prediction API written in Node.js).

These four sessions ran in the cloud. The demonstration interface replays their records locally. The durations below include reconstructing the example repository and describe this particular small experiment.

The author dispatched three sessions within 16 seconds:

1. Fix a flaky test: repair a test suite that failed roughly one-quarter of the time.
2. Rewrite API documentation: correct older documentation that had drifted from the implementation.
3. Refactor structured logging: replace concatenated log strings with JSON output.

Because each machine reconstructed the example repository from files in the prompt, preparation took between one-third and slightly more than half of its total runtime(with a real GitHub connection, this step is the normal clone operation). The three machines ran for 61 seconds, 65 seconds, and 72 seconds respectively. All finished 87 seconds after the first task started.

1. Task one: fix the flaky test and rewrite the cache race

After inspecting the code, the Agent found a race condition in TtlCache.get(a failure dependent on the ordering of concurrent operations):

• Why the old code failed: with an initially empty cache (Cold Cache), the first request starts an asynchronous load. Before it finishes, a second concurrent request for the same key arrives. The old implementation adds a cache entry only after loading finishes and returns a result. The second request therefore cannot find the work in progress and starts a duplicate load. That timing problem caused the test to fail roughly one-quarter of the time.
• The fix: store the pending Promise in the cache as soon as the request starts. Later concurrent reads wait for that shared Promise instead of loading again. Add failure cleanup as well: if loading throws an error, immediately remove its cache entry.

After making the change, the Agent ran this actual counting loop in the cloud Bash terminal:

fails=0
for i in $(seq 1 40); do
  npm test >/dev/null 2>&1 || fails=$((fails+1))
done
echo "runs=40 fails=$fails"

(Run this in cloud Bash; replace npm test with the actual test entry in package.json. Each run's output is redirected to the null device, and failures increment the counter.)

The output was runs=40 fails=0: 40 consecutive runs with no failures. This session did not reproduce the old failure before changing the code; the 40 clean runs were repeated verification after the fix.

2. Task two: update API documentation and verify actual responses

The documentation VM started the API server in the background and used curl to test every endpoint. It found 5 substantial discrepancies in the old documentation:

• It listed lat and lon fields that /stations does not return.
• The documented days parameter was already ignored by the code. The actual filtering parameters were from and hours, with a default of 24 hours.
• Heights in meters were incorrectly described as feet.
• The /next-high endpoint was missing.
• The 400 and 404 error responses were undocumented.

The Agent also found that malformed from or hours values silently return HTTP 200 and an empty list []. Rather than changing application behavior outside its scope, it documented this as a caveat.

3. Task three: structured logging and the cost of isolation

The third machine changed logging to JSON with method, path, status, and duration_ms fields, and added 5 unit tests for the logging module. When it committed, however, the suite still had 1 failing test. The Agent then reran the cache tests 8 times; 5 runs failed. It correctly identified the same cache race the first machine was fixing.

Because the cloud VMs were fully isolated, this machine could not know the first machine was already fixing that cache bug in parallel. Its own task scope also prevented it from changing the cache code. It reported honestly that the full suite had not passed.

Parallel sessions do not see one another's code changes. Split cloud tasks along file or module boundaries where possible. After merging the branches individually, run the global integration tests again to verify the combined result.

Step 5: merge branches, bring work back locally, and automate ongoing tasks

Create a PR from Diff, then verify the GitHub merge

After reviewing the changes and confirming the tests, start the merge process from the cloud:

1. Click Create PR at the top of the Diff view: Click Create PR in the upper-right of the web Diff panel. There are three ways to create the pull request:
   • Full PR: create a regular PR on GitHub, entering the repository's checks and review process.
   • Draft PR: create a draft for the team to inspect, then mark it ready for review when prepared.
   • GitHub Compose: open GitHub's creation page with a title and detailed description Claude generated from the actual changes. Adjust them before submitting.
2. Creating a PR does not merge the code: Clicking Create PR in Claude means pushing the claude/ branch to GitHub and opening a pull request. The merge must happen in the GitHub repository:
   • Open the PR on GitHub and check continuous integration (CI) results and the team's Review feedback.
   • Follow the team's Branch protection rules. When all required checks are satisfied, click Merge pull request.
3. Verify the merged target branch locally: After GitHub merges the code into the target branch, such as main, return to your local terminal, pull the latest main-branch code, and run the actual tests, such as npm test, for a final check before release.

Team and Enterprise users can also set session visibility to Team so colleagues can inspect the work. The Claude-Session trailer in cloud commits links back to the session record.

Scenario 1: clear small backlog tasks in parallel

Dispatch several accumulated tasks, such as minor API adjustments or boundary-test repairs, at once. They do not compete for local ports or workspace files. With the Pro or Max public beta of Projects, you can start up to 200 new threads per day; that work still consumes subscription usage. You can also create a coordinator session to dispatch the tasks and track their progress.

Scenario 2: long builds and repeated flaky-test verification

Use the cloud for large integration tests that need hundreds of repeated runs or intermittent-failure investigations. Foreground VM commands time out after 2 minutes by default(adjustable through BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS, in milliseconds, up to 10 minutes). After timeout, they automatically move to the background and can continue for up to 30 minutes.

Scenario 3: Plan -> Cloud -> Teleport handoff

For architectural refactoring or a large migration, move work between local and cloud environments:

# 1. Start planning mode in the local terminal to develop the approach
claude --permission-mode plan

# Once agreed, save the plan to docs/migration-plan.md, commit, and push it to the remote repository

# 2. Send the heavy work to the cloud and free your computer for other work
claude --cloud "Follow the migration plan in docs/migration-plan.md exactly"

# 3. When the cloud task finishes, bring the branch back to your local terminal
claude --teleport            # Open the cloud session selector and choose the completed task

• Ways to bring work back:
  • In the web session menu, choose Open in > Terminal to copy the resume command.
  • Run claude --teleport in your system terminal to open the interactive selector, without guessing or manually entering a session-id. You can also resume a specific session with claude --teleport <session-id>.
  • In your local Claude terminal, enter /teleport or /tp to open the selector, or press t in the /tasks list.
• Teleport prerequisites: keep your local workspace clean. If there are uncommitted changes, you will be prompted to stash them. Run from a checkout of the same repository, not a fork. The remote branch must already be pushed, and the terminal must be signed in to the same claude.ai account.
• How it works: Teleport checks out the branch locally and loads the cloud conversation history. Further local changes belong to the local copy; they do not automatically synchronize back to the cloud web session. To continue steering that local session from your phone, start /remote-control inside it.

Scenario 4: follow work on your phone and diagnose complex code

Open the Code tab in the Claude mobile app to check cloud task status and answer follow-up questions.

A mobile session can also investigate code while you are away from your desk. In the experiment, the author used a phone interface to ask a fourth session to diagnose tidepool's tide-prediction algorithm and time-window boundaries. By running code and examining its behavior, the Agent found two subtle bugs:

1. Missing boundary extrema: the loop that extracts maxima and minima visits only the middle samples, from i=1 to length-2. A high tide exactly at the beginning of the time window is therefore ignored. For example, a high at 02:12Z is missed when the window begins at 02:12Z; moving the start back one sampling step to 02:06Z lets the algorithm recognize it.
2. A 3-minute shift from choosing the first plateau sample: rounding tide heights to millimeters creates plateaus of adjacent equal-height samples. The algorithm chooses the first sample rather than the plateau's center. Shifting the window start by 3 minutes therefore moves the reported time of the same high from 02:12 to 02:15. A window starting midway through a plateau can also miss the extremum.

The Agent also listed the distribution of adjacent equal-height samples in the data:

• Gull Harbor: 90/116
• Half Moon Bay: 73/116
• Port Ellis: 39/116

These three numbers are counts of adjacent equal-height samples, not prediction accuracy. The proposed fix is to include one extra sample on each side in the calculation, then filter results back to the original window. This diagnosis ran code to investigate behavior; it did not change application source files.

Scenario 5: monitor PRs and apply automatic fixes (Auto-fix)

After installing the Claude GitHub App, enable Auto-fix directly in the web session's CI status bar. Alternatively, start Claude Code on the PR branch and enter /autofix-pr(a Claude interactive command, not a system-shell command; the CLI uses gh to detect the PR and start cloud monitoring). You can also ask the mobile app or a new session to monitor the PR.

When CI fails or a colleague adds PR review comments, Claude gathers context, investigates, and acts:

• Clear fixes: when the requested change is unambiguous and the fix is sufficiently clear, it pushes a fix commit and explains the change in the session.
• Ambiguous or architectural feedback: if a comment has multiple possible interpretations or involves an important architectural decision, Claude asks you first.
• Comment identity and automation effects: its replies in GitHub review threads appear under your linked GitHub identity and are explicitly marked Claude Code. If your team uses comment-triggered automation such as Atlantis, those replies may trigger its workflows. Assess the permission implications before enabling this.
• Merge conflicts: when changes to the target branch cause conflicts, Claude does not automatically receive a GitHub notification. Send a rebase instruction in the session to have it fetch the latest code and resolve them.

Scenario 6: scheduled and event-driven checks (Routines)

Routines(currently in research preview) bundle a prompt, repositories, connectors(Connectors), and an environment into work that runs autonomously when triggered.

Complete setup steps

1. Create a routine: open claude.ai/code/routines and click New routine(you can also create one with /schedule in a local Claude Code session).
2. Name it and supply instructions: set Name, choose Model, and write a self-contained Prompt with a clear goal and completion criteria.
3. Choose Repositories: add one or more GitHub repositories. The routine checks out their default branches and commits work to new branches prefixed with claude/.
4. Choose Environment: configure network access(for example, the default Trusted allowlist), environment variables, and the initialization setup script.
5. Set the initial Trigger:
   • Schedule: run hourly, daily, on weekdays, or weekly, or choose a one-time future run. The minimum supported interval is once per hour. Scheduled triggers do not require the GitHub App in the repository.
   • GitHub event: trigger when a PR opens or a release is published. The GitHub event trigger requires the Claude GitHub App.
6. Reduce Connectors: the form selects all connected MCP connectors by default. A Routine runs shell commands and connector calls autonomously, usually without waiting for human approval, with exceptions for some Artifact operations. Deselect irrelevant connectors to narrow write permissions and external-call risks.
7. Save and test immediately: click Create, then click Run now on the detail page to test it.
8. Open the session to verify results: in the run list, open the corresponding cloud session and inspect its actual commands, output, and generated branch. A green run-list status means infrastructure startup and exit had no errors; it does not prove the prompt's business goal succeeded. Open the session to check the actual result.

A check prompt you can copy

Review recently merged commits on the repository's main branch and run unit tests and code-style checks. If tests fail or configuration errors appear, investigate the root cause and write a fix. After running tests and confirming they all pass, push to a claude/ branch and report a summary of the changes.

Set up an external API trigger

After saving a Routine, enable its dedicated HTTP endpoint to connect external alerts or release pipelines:

1. Open the routine at claude.ai/code/routines, then select Edit from the menu beside its name.
2. Scroll to the triggers section, click Add another trigger, and select API.
3. Copy the dedicated Webhook URL and click Generate token(the token appears only once and cannot be viewed again after closing the dialog; copy it immediately into your secrets manager).
4. Copy the example curl command supplied by the platform. Use POST and an Authorization: Bearer <token> header. The JSON body can include dynamic context(such as alert details or error logs):

   ROUTINE_URL="Paste the dedicated URL shown by the platform"
   # Configure ROUTINE_TOKEN in the calling system's Secret; do not put a real token in the repository
   curl -X POST "$ROUTINE_URL" \
     -H "Authorization: Bearer $ROUTINE_TOKEN" \
     -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
     -H "anthropic-version: 2023-06-01" \
     -H "Content-Type: application/json" \
     -d '{"text": "Monitoring alert triggered; investigation context attached"}'
   

5. A successful response includes claude_code_session_id and claude_code_session_url. Open the returned session URL in your browser to follow execution live.

Usage and separate limits

Routine runs count toward normal subscription usage, which you can check at claude.ai/settings/usage. Scheduled, manual, and API runs also have separate hourly rate limits. Their trigger frequency must respect those limits; see the official usage and limits.

Scenario 7: inspect untrusted third-party code in a sandbox

Run unreviewed open-source PRs or third-party dependencies with unknown installation scripts in the cloud:

• Each VM is a disposable, isolated sandbox without your host computer's SSH keys or personal local credentials.
• Limit networking to Trusted or None. Even under None, communication with the Anthropic API and branch pushes remain allowed. Do not treat it as physical isolation that makes all data egress impossible.

Core mechanics: security boundaries, lifecycle, and usage specifications

1. Resources: each Anthropic-hosted VM uses Ubuntu 24.04 on x86_64, with approximately 4 vCPU cores, 16GB of RAM, and 30GB of disk space.
2. Credential proxy isolation: your real GitHub authorization token stays in the GitHub Proxy outside the VM. Claude inside the VM receives a short-lived, limited credential whose push permissions are restricted to its own working branch(within the VM, the credential can still read relevant repositories according to its authorization, but cannot arbitrarily push to other protected branches or delete branches).
3. Repository configuration travels with the code: CLAUDE.md, .claude/settings.json, .claude/rules/, .claude/skills/, and .mcp.json enter the VM with the Git repository and load automatically in single-repository sessions. Your local ~/.claude private user-wide configuration stays on your computer.
4. Pause, reclaim, and the data lifecycle:
   • Pause: after several minutes without activity, the VM pauses automatically and saves its disk files. Sending a new message resumes the same VM.
   • Reclaim and session retention: after prolonged inactivity, the system releases the VM entirely. Reclaiming a VM does not delete the chat history. Anthropic stores the session record; retention depends on your subscription and model-improvement settings. Deleting the session removes the corresponding data. Reopening it later allocates a new VM and restores the conversation history, but running background processes and uncommitted changes cannot be retained on the original machine. For long-lived work, have the Agent commit and push promptly; use the remote branch as the durable record of results.
5. Usage allowance and concurrent consumption: cloud sessions do not add a machine-rental bill; they use your existing plan limits. Running 5 tasks concurrently consumes allowance at roughly 5 times the rate of one session. For existing individual Pro and Max subscribers, Anthropic offers a limited-time cloud-session promotional credit($100 for Pro and $250 for Max). Claim it at claude.ai/code/claim-credit or with /claim-credit inside Claude Code. The credit applies only to cloud sessions, not Projects or Routines. After it is used up or expires, ordinary subscription usage resumes. See the promotion credit terms.
6. Model-training policy: Team and Enterprise business subscriptions do not use your code or prompts to train base models by default, unless an organization administrator opts in(org opt-in). For personal Pro and Max subscriptions, the policy depends on the Model Improvement switch in your privacy controls.