Claude Code Environments vs This Computer: When to Use Each

A Claude Code cloud environment is a saved configuration for sessions that run on a remote VM instead of your machine. Use one when the work should keep going with your laptop closed, run several tasks at once or stay away from your machine’s credentials. Stay on this computer when the work depends on something only your machine has.

Product details here were checked against the official Claude Code documentation on November 2, 2026. They change often, so follow the links before relying on one.

What is a Claude Code environment?

When you start a session, the environment selector in the desktop app decides where Claude executes. Your own machine sits under Local. The other choices are Cloud, SSH for a remote machine you connect to, and WSL on Windows. Claude Code behaves the same in each. What changes is where the session runs and whether your local configuration comes with it.

“Environment” also has a narrower meaning. In the docs, a cloud environment is the saved configuration a cloud session starts from. Each session gets its own VM, and many sessions can start from the same environment. That’s the sense used in the rest of this article, with “this computer” meaning a Local session.

What do you configure in a cloud environment?

• Network access: None, Trusted, Full or a custom list. The Default environment uses Trusted, which allows package registries, GitHub and cloud SDKs through an allowlist.
• Environment variables: values available to each session. Anyone who uses the environment can read them, so they’re the wrong place for secrets.
• Network secrets: API keys kept outside the VM and attached to requests for the hosts you list.
• A setup script: installs what the project needs. If it finishes in roughly five minutes, later sessions start from a filesystem snapshot that lasts about seven days.

You don’t start from nothing. The VM comes with common toolchains, Docker, PostgreSQL and Redis installed, though the databases aren’t running until something starts them. The snapshot keeps files and loses processes, so a database or docker compose up stack from the setup script has to be started again in each session.

How does it differ from running on this computer?

The configuration row is the easy one to miss. Your personal ~/.claude/CLAUDE.md, user-level skills and locally added MCP servers don’t follow you to the cloud. The repository’s CLAUDE.md, .claude/ skills and .mcp.json do. If Claude behaves well on your laptop and worse in the cloud, compare what’s committed with what only exists in your home directory.

Why use a cloud environment instead?

• The work outlasts your laptop. A cloud session keeps running after you close it, and you can check on it or steer it from a browser or phone.
• Tasks run in parallel without competing for one machine. Local worktrees keep parallel sessions’ files apart, but they still share your CPU, ports and databases. Each cloud session gets its own VM.
• Your machine stays out of reach. Locally, Claude Code’s Bash sandbox is off by default, and once on, it still lets commands read most of the machine, including ~/.ssh and ~/.aws/credentials, unless you narrow it. In an Anthropic-hosted cloud session, Git credentials stay outside the sandbox and those home-directory files were never there.
• Every run starts from the same place. A committed instruction file and a setup script give each session a clean clone instead of whatever state your machine happens to be in, which also tests whether the repository is complete enough to work from.

Why stay on this computer?

• The work needs something only your machine has: gitignored settings, a local database with real data, a VPN or a signed-in browser.
• The target isn’t Linux on x86_64. The VM runs that regardless of your own hardware, so anything that needs macOS, such as an iOS simulator, belongs on your own machine.
• The job is too big for the VM. Anthropic lists approximate ceilings of 4 vCPUs, 16 GB of RAM and 30 GB of disk, and it may stop tasks that need significantly more memory.
• The repository isn’t on GitHub. You can send a bundle of a GitLab or Bitbucket repository to a cloud session, but the session can’t push back to that remote.
• Your organization rules it out. Zero Data Retention, the HIPAA configuration and customer-managed keys all block cloud sessions, and an organization IP allowlist makes Anthropic-hosted ones fail unless Anthropic exempts them.
• You’re watching closely. If you’re reading each change and checking it in a local dev server, a remote VM adds a step and gives you little back.

Staying local also means carrying the risk yourself. Permission prompts only protect you if you read them, and sensitive files in the working folder are within Claude’s reach.

How can a different environment give you a misleading result?

This has happened on this site with no cloud involved. A fresh Git worktree doesn’t have the gitignored .env.production.local. Building there left a contact setting empty, the contact page rendered different text, the build gave that page a new last-modified date, and npm run validate still passed. In another case, a browser test passed in worktrees with a symlinked node_modules and failed in the main checkout, matching what production measured. Fonts not loading through the symlink is the best guess, and it hasn’t been confirmed.

Both were green checks from a setup that had drifted from the one that mattered. A cloud VM can drift the same way, and further, because it starts with less of your machine. Before trusting a green result, ask what that environment was missing.

Does a cloud environment cost more?

Anthropic lists no separate charge for the cloud VM. Cloud sessions count toward your plan’s limits alongside your other Claude and Claude Code usage, so the cost that changes is how much you run: parallel tasks use limits proportionately faster. Cloud sessions also need a claude.ai sign-in, while a local session will bill per token at API rates if ANTHROPIC_API_KEY is set, so check that before assuming your plan is paying. The economics of AI coding go wrong in other ways too, wherever the code runs.

The real cost is upkeep. Someone has to write the setup script, keep it inside the caching window and update it when the project moves. Three parallel sessions and a custom environment for a job that runs once is architecture you’re better off not building.

Can you move work between the two?

Yes, with limits. claude --cloud starts a new cloud session from your terminal, cloning your branch from GitHub, so push first. claude --teleport pulls a cloud session into a local checkout once its branch has been pushed. From the command line that’s one-way: an existing terminal session can’t be pushed to the cloud, though the desktop app can send a local session there from its Open in menu.

Push your work as you go. When an idle VM is reclaimed, your conversation comes back on a fresh VM but background work doesn’t, so treat anything unpushed as at risk.

The same task in both places

This is a hypothetical example, and neither path has been measured. Say the job is adding a two-question FAQ to an existing post on this site, where the visible answers and structured data have to stay consistent.

This one suits the computer with the production settings on it, because the build can’t be trusted without them. Ten similar edits queued for overnight would change the answer, as long as the environment’s setup was fixed first. Either way, the answers still need a person to read them, since passing the audits doesn’t make them correct.

A checklist for deciding

• Does the work depend on a gitignored file, a local service, a VPN or a signed-in browser? Stay on this computer.
• Does it need macOS, or more than the VM’s roughly 4 vCPUs and 16 GB of RAM? Stay on this computer.
• Does it need to finish after you close the laptop? Use a cloud environment.
• Do you want several tasks running without sharing ports, databases and CPU? Use a cloud environment.
• Is there anything on your machine that Claude shouldn’t be able to read? Prefer a cloud environment, or narrow the local sandbox.
• Is the repository complete without your home directory? If not, commit the shared instructions before relying on the cloud.
• Can the check you trust run in the cloud, and would it fail there for the right reasons? If not, stay local until it can.

Short answers