Skip to main content
Cloud sessions are available on Pro, Max, and Team plans, and for Enterprise users with premium seats or Chat + Claude Code seats. If custom roles govern your access, you also need a role with the cloud sessions permission to start sessions on Anthropic’s infrastructure from the browser, apps, or terminal. Ask an Owner to add it to one of your roles at Organization settings > Roles.
A cloud session is a Claude Code session that runs on cloud infrastructure instead of on your machine. By default it runs on infrastructure Anthropic manages, or on your organization’s self-hosted environment when routed there. The session keeps running after you close your laptop, and you can check on it or steer it from any device. It counts toward your plan’s usage limits alongside the rest of your Claude and Claude Code usage, and there’s no separate charge for the cloud VM. To let cloud sessions clone your code from GitHub and push branches, connect GitHub with one of the GitHub connection methods. If your repository is on GitLab, Bitbucket, or another host, see Platform restrictions for what works. You can start a cloud session from any of these surfaces: Once you’re set up, use this page to move work between your terminal and the cloud, manage and share sessions, turn on auto-fix for pull requests, and troubleshoot.
These cases are covered on other pages:
  • Starting your first cloud session: Get started with cloud sessions connects GitHub and walks through a task in the browser
  • Many cloud sessions for one body of work: a project has Claude start and keep track of them for you
  • Steering a local session from another device: sessions in your terminal, IDE, or the Desktop app with Local selected run on your machine, and Remote Control lets you reach them from your phone or browser

​
Cloud environments

Every cloud session runs in a cloud environment, the saved configuration that controls network access, environment variables, and setup scripts.

​
GitHub authentication options

Cloud sessions need access to your GitHub repositories to clone code and push branches. You can grant access in two ways: These features depend on the Claude GitHub App being installed on the repository:
  • Auto-fix: installing the Claude GitHub App on a repository also enables Auto-fix for pull requests in it
  • Projects: threads in a project need the Claude GitHub App installed on each repository they clone, whichever method you connected with. See Set up GitHub access
In Anthropic-hosted environments, your GitHub credentials stay encrypted on Anthropic’s servers and never enter a session’s VM. GitHub operations from the VM go through the GitHub proxy, which attaches the credential on the server side. See Connect from your terminal for the /web-setup walkthrough, including what /web-setup stores and how to remove it.
Organizations with Zero Data Retention enabled, or with the HIPAA configuration applied, can’t use /web-setup or other cloud session features. Organizations that use customer-managed encryption keys (CMEK) can’t start cloud sessions either.

​
Quick setup for Team and Enterprise

Quick setup is an organization setting that removes steps from members’ GitHub and environment setup. On Team and Enterprise plans it’s off by default. Here’s what changes for members when it’s on:
  • /web-setup: members can connect GitHub with /web-setup. While the setting is off, the command is hidden
  • GitHub App prompt: browser onboarding skips the Claude GitHub App install prompt
  • First environment: browser onboarding creates the Default environment for members instead of showing the environment form
An Owner turns it on with the Quick setup toggle at Organization settings > Claude Code.

​
Move tasks between terminal and cloud

These workflows require the Claude Code CLI signed in to the same claude.ai account. You can start new cloud sessions from your terminal, or pull cloud sessions into your terminal to continue locally. Cloud sessions persist even if you close your laptop, and you can monitor them from anywhere including the Claude mobile app.
From the CLI, session handoff is one-way: you can pull cloud sessions into your terminal with --teleport, but you can’t push an existing terminal session to the cloud. The --cloud flag with a task description creates a new cloud session for your current repository; with -p and a session ID or claude.ai/code URL it instead queues a message into that existing session. The Desktop app can send a local session in its Code tab to the cloud from its Open in menu.

​
Start a cloud session from your terminal

Start a cloud session from the command line with the --cloud flag:
This creates a new cloud session on claude.ai. The cloud VM clones your current directory’s GitHub remote at your current branch, not your local checkout, so push first if you have local commits. See Send local repositories without GitHub for the cases where Claude Code uploads your local repository instead of cloning. If the terminal prints Branch <name> is not on GitHub, see Branch is not on GitHub. --cloud works with a single repository at a time. The task runs in the cloud while you continue working locally. The older --remote spelling still works as a deprecated alias for --cloud. While the cloud container starts, the CLI shows a live checklist of setup steps, such as cloning the repository and running your setup script. It queues messages you type during provisioning and sends them once the session is ready.
--cloud creates cloud sessions. --remote-control is unrelated: it lets you monitor and steer a local CLI session from claude.ai or the Claude app. See Remote Control.
Open the session on claude.ai or the Claude mobile app to check progress or interact directly. From there you can steer Claude, provide feedback, or answer questions as in any other conversation. If Claude asks a question and the session sits idle, you can still answer when you come back, up to environment expiry, and the session continues from your answer.

​
Tips for cloud tasks

Plan locally, execute in the cloud: for complex tasks, start Claude in plan mode to collaborate on the approach, then send work to the cloud:
In plan mode, Claude reads files, runs commands to explore, and proposes a plan without editing source code. Once you’re satisfied, save the plan to the repo, commit, and push so the cloud VM can clone it. Then start a cloud session for autonomous execution:
Run tasks in parallel: each --cloud command creates its own cloud session that runs independently. You can start multiple tasks and they’ll all run simultaneously in separate sessions:
When a session completes, you can create a PR from claude.ai/code or teleport the session to your terminal to continue working.

​
Send local repositories without GitHub

When you run claude --cloud from a repository that has no git remote, or from a github.com repository that the Claude GitHub App isn’t installed on, Claude Code bundles your local repository and uploads it directly to the cloud session. This applies even if you connected GitHub with /web-setup. For a full clone, the bundle includes your repository history across all branches, plus uncommitted changes to tracked files. What happens to uncommitted changes in sensitive files depends on your platform:
  • macOS, Linux, and WSL: Claude Code leaves uncommitted changes to files named like credentials or keys out of the upload. This includes .env files, Terraform *.tfvars files, and key files such as id_rsa and *.pem. It also leaves out uncommitted changes to files that a git filter such as Git LFS manages. A Left on this machine: notice names the files left out, and the session starts with the committed version of each, or without the file if none is committed.
  • Native Windows: uncommitted changes to tracked files upload as they are, whatever the file’s name. Stash or revert an edit you don’t want in the cloud session before you start it.
To upload a bundle even when Claude Code would otherwise clone from the remote, set CCR_FORCE_BUNDLE=1:
Bundled repositories must meet these limits:
  • The directory must be a git repository with at least one commit
  • The bundled repository must be under 100 MB. Larger repositories fall back to bundling only the current branch, then to a single squashed snapshot of the working tree, and fail if the snapshot is still too large
  • Untracked files are not included; run git add on files you want the cloud session to see
  • On macOS, Linux, and WSL, Claude Code refuses the upload when it can’t follow a git setting that affects which attribute rules apply to your files, such as core.attributesFile set in an included config file. The refusal message names the setting and the fix
  • Sessions created from a bundle can push back to a GitHub remote only when your GitHub connection has push access to that repository
On macOS, Linux, and WSL, the upload also needs git 2.31 or later and a checkout layout it supports, while on native Windows Claude Code uploads without either check. When a checkout doesn’t meet those requirements, Claude Code doesn’t start the session. It prints an error that contains Not uploading this working tree:, names the cause, and says what to change. These are the common causes:
  • Older git: the installed git is older than 2.31. Update git, then retry.
  • A checkout layout the upload doesn’t support: you started inside a submodule, in a clone made with git clone --separate-git-dir, --shared, or --reference, in a checkout with core.worktree set, or in a repository that keeps its refs in the reftable format. Start from the main checkout of a clone made with a plain git clone instead.
  • A linked worktree with a sparse checkout: git sparse-checkout writes settings to the worktree’s own config.worktree file, which the upload doesn’t accept, so a worktree that has those settings isn’t uploaded, and neither is one Claude Code created with worktree.sparsePaths. Start from the repository’s main checkout instead.
  • Git configuration kept inside the working tree: your git configuration includes a file that sits inside the checkout, for example an include.path entry that points into the repository. Move that file outside the working tree or remove the include, then retry.
On macOS, Linux, and WSL, a partial clone made with git clone --filter uploads as a snapshot of its working tree without history, as long as the clone holds every tracked file locally. For claude --cloud, if the repository is on GitHub, you can avoid the upload and its requirements: push your branch, install the Claude GitHub App on the repository, and start the session again so that it clones from GitHub.

​
Send follow-ups from the CLI

Once a cloud session is running, wherever it executes, send it a follow-up message from the claude CLI on any machine where you’re logged in with claude auth login. The CLI authenticates with your Anthropic account credentials and sends no local session state, so the command doesn’t need to run from the machine that started the session. The command posts one message and exits:
The CLI queues the message into the session and exits without waiting for a reply. Use it to steer a long-running session, queue the next step while the current one is still finishing, or send follow-ups from a CI script. You can also pipe the message on stdin instead of passing it as an argument: echo "your message" | claude -p --cloud <session-id>. For <session-id>, pass the bare ID, such as session_... or cse_..., or the session’s claude.ai/code/<id> URL, with or without the scheme or query string. Find the ID in your session list at claude.ai/code.
--cloud requires an Anthropic account. It’s not available when Claude Code is configured for Amazon Bedrock, Google Cloud’s Agent Platform, or another third-party provider. An LLM gateway configured only through ANTHROPIC_BASE_URL doesn’t count as a third-party provider for this check, but you still need to sign in with claude auth login. Your organization’s allow_remote_sessions policy must also be enabled. An Owner can turn it on in the Claude Code admin settings at claude.ai/admin-settings/claude-code.

​
Output

On success, the command prints the session ID and a link to view the session:
Pass --output-format json for a machine-readable result: {ok, session_id, url} on success, or {ok: false, session_id, error} when the send fails, for example when the session is missing or archived. Configuration errors, such as an unsupported provider or a disabled organization policy, print to stderr without JSON. --output-format stream-json isn’t supported with --cloud <session-id>. If the send fails, see Errors when sending to a cloud session.

​
Continue a cloud session in your terminal

Pull a cloud session into your terminal using any of these:
  • Using --teleport: from the command line, run claude --teleport for an interactive session picker, or claude --teleport <session-id> to resume a specific session directly. If you have uncommitted changes, you’ll be prompted to stash them first.
  • Using /teleport: inside an existing CLI session, run /teleport or /tp to open the same session picker without restarting Claude Code.
  • From /tasks: run /tasks to see your background sessions, then press t to teleport into one.
  • From claude.ai/code: select Open in > Terminal from the session menu to copy a command you can paste into your terminal.
  • From inside the cloud session: type /teleport and Claude Code replies with the exact claude --teleport <session-id> command for that session, ready to run from a checkout of the repository. Requires Claude Code v2.1.223 or later in the session’s environment.
When you teleport a session, Claude verifies you’re in the correct repository, fetches and checks out the branch from the cloud session, and loads the full conversation history into your terminal. The terminal gets its own copy of the session: new work there stays local and doesn’t appear in the cloud session on claude.ai or the Claude mobile app. To keep steering from your phone after teleporting, start /remote-control in the local session. --teleport is distinct from --resume. --resume reopens a conversation from this machine’s local history and doesn’t list cloud sessions; --teleport pulls a cloud session and its branch.

​
Teleport requirements

Teleport checks these requirements before resuming a session. If any requirement isn’t met, you’ll see an error or be prompted to resolve the issue. When teleport fetches the session’s branch, the fetch never waits for input in your terminal. If git or ssh would ask for a password, a key passphrase, or confirmation of a new SSH host, the fetch fails, and the checkout then works only if your local clone already has the branch. For the two SSH cases, load your key into ssh-agent and run git fetch once by hand first to record the host.

​
--teleport is unavailable

Teleport requires claude.ai subscription authentication. Find the case that matches yours:
  • You’re authenticated via API key: run /login to sign in with your claude.ai account instead
  • The error names your provider: cloud sessions aren’t available through third-party providers. See the error table
  • You’re already signed in via claude.ai: your organization may have disabled cloud sessions

​
Work with sessions

Sessions appear in the sidebar at claude.ai/code. From there you can review changes, share with teammates, archive finished work, or delete sessions permanently.

​
Permission modes in cloud sessions

You pick a cloud session’s permission mode from the mode dropdown, both when you create the task and while the session runs. Claude Code resumes a session in the permission mode it was in when you do either of these:

​
Review changes

After Claude pushes its changes to a branch, the Changes card in the panel beside the chat shows the lines added and removed, such as +42 -18. Click the line counts on the Changes card to open the diff view.
  • You can also click Changes in the session’s title bar, or in the bar’s ⋮ menu.
  • To show the panel when it’s hidden, click the Show session rail icon in the session’s title bar, or in the bar’s ⋮ menu.
In the diff view, you can comment on lines and compare against another branch:
  • Comment: leave inline comments on specific lines, then send the comments to Claude with your next message
  • Compare: the diff view compares the session’s changes against its base branch by default. To compare against any other branch in the repository, select Compare against and pick one
Claude Code computes these diffs from raw git blob content, so diff drivers and textconv filters configured in the repository don’t apply. These steps are covered elsewhere:

​
Manage context

Cloud sessions support built-in commands that produce text output. Commands that only run in the terminal interface, such as /plugin or /resume, aren’t available. Commands that open a picker or panel in the terminal behave differently in cloud sessions:
  • /model, /effort, /color, and /rename: pass the value as an argument, for example /model sonnet, instead of opening the terminal picker or slider. The argument forms follow each command’s availability notes.
  • /fast: toggles fast mode for the session when fast mode is available on your account. Requires Claude Code v2.1.271 or later in the session’s environment.
  • /config: in your browser at claude.ai/code, opens the Claude Code section of your settings instead of setting a value. To change a setting for a cloud session, set an environment variable on the environment. In a session with one repository outside a project’s threads, commit the key to that repository’s .claude/settings.json instead. Settings in cloud sessions lists what each session reads.
For context management in a cloud session outside a project’s threads: Auto-compaction runs automatically when the context window approaches capacity. Cloud sessions set CLAUDE_AUTOCOMPACT_PCT_OVERRIDE themselves, so compaction triggers partway through the auto-compact window rather than when the window fills. That value overrides one you add in your environment variables, so adding the variable there doesn’t change when compaction triggers. To change the auto-compact window instead, set CLAUDE_CODE_AUTO_COMPACT_WINDOW in your environment variables, or run /autocompact with a token count in a session where the variable isn’t set. Subagents work the same way they do locally. Claude can spawn them with the Agent tool to offload research or parallel work into a separate context window, keeping the main conversation lighter. Outside a project’s threads, subagents defined in your repo’s .claude/agents/ load automatically. Agent teams are off by default but can be enabled by adding CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 to your environment variables.

​
Take back a queued message

If you send a message while Claude is working, the message queues until Claude reads it. To take a queued message back, click the ✕ on it. The text returns to the message box so you can edit it or send something else. If Claude has already read the message, it stays in the conversation.

​
Share sessions

To share a session, toggle its visibility according to the account types below. After that, share the session link as-is. Recipients see the latest state when they open the link, but their view doesn’t update in real time.

​
Share from an Enterprise or Team account

Sharing works as follows for Enterprise and Team accounts:
  • Visibility options: Private and Team. Team visibility makes the session visible to other members of your claude.ai organization
  • Repository access: verification is enabled by default, based on the GitHub account connected to the recipient’s account
  • Your name: your account’s display name is visible to all recipients with access
  • Slack sessions: Claude in Slack sessions are automatically shared with Team visibility

​
Share from a Max or Pro account

Sharing works as follows for Max and Pro accounts:
  • Visibility options: Private and Public. Public visibility makes the session visible to any user logged into claude.ai
  • Repository access: verification isn’t enabled by default
  • Sensitive content: check your session before sharing. Sessions may contain code and credentials from private GitHub repositories
To require recipients to have repository access, or to hide your name from shared sessions, go to Settings > Claude Code > Sharing settings.

​
Archive sessions

Archive a session to remove it from the sidebar’s session list. To archive one, hover over it in the sidebar, open its ⋯ menu, and select Archive.

​
Find an archived session

To see your archived sessions, go to claude.ai/code/sessions and open the Archived tab. To put one back in the sidebar’s session list, hover over it on that tab, open its ⋮ menu, and select Unarchive.

​
Delete sessions

Deleting a session permanently removes the session and its data. This action can’t be undone. Delete a session from the sidebar, from the session menu, or from the Archived tab if you’ve already archived it:
  • From the sidebar: hover over the session, open its ⋯ menu, and select Delete
  • From the session menu: open a session, select the dropdown next to the session title, and select Delete
  • From the Archived tab: hover over the session on the Archived tab, open its ⋮ menu, and select Delete
You will be asked to confirm before a session is deleted.

​
Auto-fix pull requests

Claude can watch a pull request and automatically respond to CI failures and review comments. Claude subscribes to GitHub activity on the PR, and when a check fails or a reviewer leaves a comment, Claude investigates and pushes a fix if one is clear.
Auto-fix requires the Claude GitHub App to be installed on your repository. If you haven’t already, install it from the GitHub App page.
There are a few ways to turn on auto-fix depending on where the PR came from and what device you’re using:
  • PRs created in a cloud session: open the session at claude.ai/code and find the pull request in the Changes card. Open the ⋮ menu next to the pull request’s title and turn on Auto-fix
  • From your terminal: run /autofix-pr while on the PR’s branch. Claude Code detects the open PR with gh, spawns a cloud session, and turns on auto-fix in one step
  • From the mobile app: tell Claude to auto-fix the PR, for example “watch this PR and fix any CI failures or review comments”
  • Any existing PR: paste the PR URL into a session and tell Claude to auto-fix it
To stop monitoring, turn off Auto-fix in the pull request’s ⋮ menu in the session’s Changes card, or tell Claude to stop watching the PR.

​
How Claude responds to PR activity

When auto-fix is active, Claude receives GitHub events for the PR including new review comments and CI check failures. For each event, Claude investigates and decides how to proceed:
  • Clear fixes: if Claude is confident in a fix and it doesn’t conflict with earlier instructions, Claude makes the change, pushes it, and explains what was done in the session
  • Ambiguous requests: if a reviewer’s comment could be interpreted multiple ways or involves something architecturally significant, Claude asks you before acting
  • Duplicate or no-action events: if an event is a duplicate or requires no change, Claude notes it in the session and moves on
GitHub does not emit a webhook when the base branch advances and creates a merge conflict, so auto-fix can’t react to conflicts on its own. To resolve a conflict, open the session and ask Claude to rebase. Claude may reply to review comment threads on GitHub as part of resolving them. These replies are posted using your GitHub account, so they appear under your username, but each reply is labeled as coming from Claude Code so reviewers know it was written by the agent and not by you directly.
If your repository uses comment-triggered automation such as Atlantis, Terraform Cloud, or custom GitHub Actions that run on issue_comment events, be aware that Claude can reply on your behalf, which can trigger those workflows. Review your repository’s automation before enabling auto-fix, and consider disabling auto-fix for repositories where a PR comment can deploy infrastructure or run privileged operations.

​
Security and isolation

Each cloud session is separated from your machine and from other sessions through several layers:
  • Isolated virtual machines: each session runs in an isolated, Anthropic-managed VM. Sessions your organization routes to a self-hosted environment run on your own infrastructure instead, where isolation is your deployment’s responsibility
  • Network access controls: in Anthropic-hosted environments, network access is limited by default and can be disabled. See Network access for the access levels, the default allowed domains, and the traffic that doesn’t go through the allowlist. In a self-hosted environment, you restrict session egress at your own network boundary. When running with network access disabled, Claude Code can still communicate with the Anthropic API, which may allow data to exit the VM.
  • Credential protection: 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. In a self-hosted environment, your deployment supplies git credentials; see Configure git
  • Network secrets: in Anthropic-hosted environments, keys you add to a cloud environment stay outside the sandbox the same way, attached to matching requests after they leave the session. A self-hosted environment doesn’t have network secrets
  • Secure analysis: code is analyzed and modified within the session’s isolated environment before creating PRs

​
Troubleshooting

For runtime API errors that appear in the conversation such as API Error: 500, 529 Overloaded, 429, or Prompt is too long, see the Error reference. Those errors and their fixes are shared with the CLI and Desktop app. The sections below cover issues specific to cloud sessions.

​
Session creation failed

If a new session fails to start with Session creation failed or stalls at provisioning, Claude Code could not allocate a VM for the session.

​
Your new session couldn’t start

Your prompt is back in the box you sent it from.
  • Connection lost: check your internet connection and any VPN or proxy you use, then send your prompt again
  • Server error: wait a moment, then send your prompt again. If the notice reappears, check status.claude.com

​
Can’t rewind to this message

Rewind to here fails with this error on any message except the newest when your session runs on a self-hosted runner with Claude Code before v2.1.246. Ask whoever runs your organization’s runners to upgrade them.

​
Unable to get organization UUID

claude --cloud and claude --teleport require sign-in with a claude.ai account. If you authenticate with an API key, or your stored account details are stale, you see one of these:
  • Unable to get organization UUID
  • Cloud sessions need a claude.ai sign-in. Run `claude auth login` (or /login in a local session), then try again.
  • Error loading Claude Code sessions in the session picker, when you run claude --teleport without a session ID
Run claude auth login in your shell to sign in with your claude.ai account, then retry the command. Inside a running session, /login does the same. If the error names your provider instead, see the error table: cloud sessions aren’t available through third-party providers. From v2.1.274 through v2.1.289, the sign-in message read Claude Code cloud sessions require authentication with a Claude.ai account. API key authentication is not sufficient. Please run /login to authenticate, or check your authentication status with /status.

​
Branch is not on GitHub

When claude --cloud prints a line starting with Branch <name> is not on GitHub, the cloud session still starts, but not from your branch. The line names where the session starts instead: a pushed commit from your branch’s history, or the repository’s default branch. Commits that exist only on your machine and uncommitted changes aren’t in the session. You see this line when, for example, you never pushed the branch, or GitHub deleted it after its pull request merged. If the starting point the line names has what your task needs, use the session as it is. Otherwise, push the branch and start a new session so that it clones your branch.

​
Remote Control session expired or access denied

--teleport connects through the same Remote Control session infrastructure that cloud sessions use, so authentication and session-expiry errors surface with Remote Control wording. You may see Remote Control session expired or Access denied. The connection token is short-lived and scoped to your account.
  • Run /login locally to refresh your credentials, then reconnect
  • Confirm you are signed in to the same account that owns the session
  • If you see Remote Control may not be available for this organization, an Owner has not enabled cloud sessions for your organization

​
Errors when sending to a cloud session

These errors come from running claude with --cloud <session-id>, with or without -p. The CLI prefixes errors with Error: . A failed delivery is wrapped as failed to send message to cloud session <id>: <reason>.

​
Environment expired

Cloud sessions stop after a period of inactivity and the session’s VM is reclaimed. A session counts as inactive while it waits for you to approve an MCP connector tool call or to sign in to an MCP server, and it can expire during that wait. Reopen the session from claude.ai/code to provision a fresh VM:
  • Restored: your conversation history
  • Not restored: background work that was still running or pending when the VM was reclaimed, including:
    • Shell commands: Claude Code tells Claude which commands stopped. Ask Claude to rerun the ones you still need.
    • Subagents: Claude Code tells Claude which subagents stopped, and which of those can be resumed instead of started over. Ask Claude to continue their work.
    • Session-scoped scheduled tasks: tasks you scheduled in the session and a /loop waiting for its next iteration don’t carry over to the reopened session. Ask Claude to schedule the tasks again, or run /loop again to restart the loop.

​
Limitations

Before relying on cloud sessions for a workflow, account for these constraints:
  • Rate limits: cloud sessions share rate limits with all other Claude and Claude Code usage within your account. Running multiple tasks in parallel consumes more rate limits proportionately.
  • Time limits: commands Claude runs and SessionStart hooks have default timeouts you can change, and a setup script is cached only when it finishes in roughly five minutes. See Time limits
  • Repository authentication: you can only pull a cloud session into your terminal when you are authenticated to the same account
  • Platform restrictions: repository cloning and pull request creation require GitHub. Self-hosted GitHub Enterprise Server instances are supported for Team and Enterprise plans. You can send a GitLab, Bitbucket, or other non-GitHub repository to a cloud session as a local bundle by setting CCR_FORCE_BUNDLE=1, but the session can’t push results back to that remote
  • Organization IP allowlist: cloud sessions call the Anthropic API from Anthropic-managed infrastructure, not your network, while sessions in a self-hosted environment call it from your own network. If your organization has IP allowlisting enabled, every Anthropic-hosted cloud session fails with an authentication error.
    • Code Review and scheduled tasks: the same applies to Code Review and to cloud scheduled tasks that run on Anthropic-hosted environments. A scheduled task routed to a self-hosted environment calls the API from your own network.
    • Getting an exemption: contact Anthropic support to exempt Anthropic-hosted services from your organization’s IP allowlist.
  • Cloud environments: configure network access, environment variables, and setup scripts for cloud sessions
  • Projects: one conversation where Claude coordinates parallel cloud sessions on your repositories and reports back
  • Ultrareview: run a deep multi-agent code review in a cloud sandbox
  • Cloud scheduled tasks: automate work on a schedule, via API call, or in response to GitHub events
  • Hooks configuration: run scripts at session lifecycle events
  • All settings: all configuration options
  • Security: isolation guarantees and data handling
  • Data usage: what Anthropic retains from cloud sessions
  • Claude Tag: an organization-managed @Claude in Slack that runs on the same cloud infrastructure