I kicked off three refactoring tasks from a browser tab, closed the laptop, and checked the results from my phone over dinner. All three sessions kept running — they weren't on my machine at all.
That's Claude Code on the web: same Claude Code, but the session runs on Anthropic-managed cloud infrastructure at claude.ai/code.
What you'll see in this post
- When cloud sessions beat local ones (and when they don't)
- How to start a task and what the environment looks like
- Moving a session between web and terminal with
--teleport - The network-access model that trips everyone up once
When the cloud session wins
Three situations where I reach for the web instead of my terminal:
The repo isn't on my machine. Web sessions clone from GitHub directly. Reviewing a teammate's project or patching a repo you've never touched needs zero local setup.
I want parallelism without terminal sprawl. Each task runs in its own isolated cloud sandbox. Fire off three independent tasks, monitor all of them from one page — or from the Claude mobile app.
I'm about to walk away. Sessions persist when the browser closes. This is what makes walk-away workflows real: submit, leave, review later.
Starting a task
Go to claude.ai/code, connect your GitHub account (first time only), pick a repository, describe the task. Claude clones the repo into a sandboxed environment, works, and shows you the diff. From there you can review changes and create a PR.
✅ Done right, the loop is: submit task → close tab → get back to a finished session with a reviewable diff and a one-click PR.
Moving between web and terminal
This is the underrated part. Two flags connect the worlds:
claude --remote
sends a task to the cloud from your terminal.
claude --teleport
pulls a running web session down to your terminal, history and all — for when the task turns out to need local context after all.
Things that surprised me
💡 Your settings travel with you. The cloud environment picks up your CLAUDE.md and project config from the repo, so sessions behave like your local ones.
💡 Setup scripts are cached. If your project needs dependencies installed, the environment remembers the result instead of re-running the script every session.
⚠️ 🔍 From the docs: the default network access is a trusted allowlist — package registries and common dev domains work, but requests to your own API fail with a 403 andx-deny-reason: host_not_allowed. If a task needs to call your staging server, edit the environment's network access first. This is the #1 "why is it failing in the cloud but not locally" cause.
⚠️ 🔍 From the docs: by default, pushes go toclaude/-prefixed branches only. Direct pushes to existing branches are a per-repo opt-in.
What it can't do
❌ No local files. Uncommitted changes, local databases, your
.env— none of it exists in the cloud sandbox. For tasks that need your machine, use Remote Control instead (local session, remote interface).
❌ It's a research preview — available on Pro, Max, Team, and Enterprise, with rate limits that may change.
The takeaway
Local Claude Code is a pair programmer. Cloud sessions are more like a small team you can hand tickets to. The skill that transfers: writing task descriptions precise enough that you'd be comfortable not watching the work happen.
Docs: Claude Code on the web.