Claude Code in the cloud: assigned from my phone, finished in the terminal

On Monday I ran the script that pulls my site's weekly stats, and the week that had just ended was missing from the data. I dug into why and found it wasn't a bug: the script deliberately waits two days, because Search Console delivers its data late. I'd put that in myself and forgotten. I wanted tests for it so it wouldn't surprise me again — a small, well-bounded task, no tokens involved, but I wasn't at a computer. So I assigned it to Claude Code from my phone, let it run in the cloud, and only sat down at the terminal for the review and the merge.

(How I move work between Windows and a Mac through one private repo is covered in One repo, two keyboards. A cloud session is basically a third machine — except I don't have to sync it; it clones the repo straight from GitHub. And the script that got the tests is the one pulling numbers from Analytics and Search Console — how it came to be is in Google Analytics over MCP.)

What it actually is

Cloud sessions are Claude Code running on Anthropic's machine instead of mine. The mobile app has a Code tab, the web has the same: I pick a repo connected through GitHub, type the assignment, and the session spins up in a sandbox — a fresh VM with Ubuntu 24.04 that clones the repo and gets to work. It pushes results to its own claude/* branch and doesn't touch main.

Two things I wanted to know first: does it cost extra? No — no API credits; cloud runs are part of the subscription and share rate limits with everything else (it's a research preview for Pro, Max and Team accounts). And what does that machine see? Just the repo. CLAUDE.md and .claude/ from the repo yes; my local ~/.claude, uncommitted work and secrets no. The network defaults to an allowlist of package registries.

How the run went

The assignment went from my phone — Czech in the original, translated here:

Add tests for scripts/analytics_snapshot.py — the iso_week_id, week_range and closed_weeks functions. Above all, watch the closed_weeks behaviour: the last safe Sunday is today minus 2 days (on Monday it must not take the week that ended yesterday; from Tuesday on it's fine). The script has doctests — decide yourself whether running them with the doctest runner is enough or whether to write unittest, and wire it into the npm scripts so everything runs with one command. Don't touch the network functions; test only the date logic, no tokens.

The session cloned the repo, read CLAUDE.md and the memory files, and got to work. The first stumble wasn't in my code: its node tests failed on missing node_modules. A fresh machine, none of my local state — it had to run npm install first. It reported that honestly in the summary, noting it had nothing to do with the change.

I'd deliberately left one decision open in the assignment: doctest runner, or unittest? It picked a unittest that swallows the doctests via load_tests — and explained why: the doctests in the script are three one-line examples, they work as documentation, but they don't guard the most fragile part — that something does not happen (on Monday, yesterday's Sunday isn't taken). That pleased me more than the code itself.

The result is 19 tests. They walk the week day by day and check when each week may be taken, run the same check across all of 2026, and don't skip the year boundary or the aligning of the download start to a Monday. The session also verified the tests actually catch a regression: it changed the two-day wait to one and four tests failed. Plus the small stuff around it — npm test now runs the node and python suites with one command, __pycache__ went into .gitignore, and the tests section in CLAUDE.md got updated. All pushed to claude/analytics-snapshot-tests-pczh5n.

A commit from the cloud has a Claude-Session: line at the end of its message with a link to the session that made it — so git log can always tell where a change came from. And the session didn't open a PR on its own: it asked whether it should. The merge stays with me, and that's how it should be.

Diffs take inline comments straight from the phone, and the session responds to them. I didn't use that this time — I wanted to go through the diff at the terminal anyway.

Teleport to the terminal

At home, all it takes in the terminal is:

cd path/to/repo
claude --teleport

The command lists cloud sessions to take over; Enter — and the session continues locally: it fetches the branch, checks it out and picks up the conversation with its full context. What appeared on screen was the complete summary of the cloud run, as if I'd been sitting next to it the whole time. The commands are the same on Windows and Mac.

Then the usual routine: go through the diff, run the tests locally — 155 node + 19 python, all green — and merge into main. One Windows note: npm run test:py calls python3, which usually isn't there; I run python -m unittest discover -s tests/analytics -p "test_*.py" directly.

Traps and guardrails

• Teleport wants its own terminal. It can't be launched from inside a running Claude session — it's an interactive command. New window, cd into the repo, then claude --teleport.
• Teleport switches the branch. It checks out the cloud session's branch — and if another session or another window has the same repo open, its working tree changes under its hands. My files "went back in time" by a day, because the branch was cut from an older main. The commits were fine, and git switch main after closing the session puts everything back — it's just good to know what's going on.
• Two sessions, same name. The picker offered me two entries called "Tests for analytics_snapshot.py", equally old — and it shows no session ID and no branch. Which one is right only becomes clear inside, from the checked-out branch and the history; otherwise Esc and try the other. The Claude-Session: line at the end of the commit message helps too.
• Pushes go only to its own branch. Git credentials never make it into the VM — pushes go through a proxy and only pass for the session's own branch. The cloud won't write to main.
• A fresh machine every time. The sandbox starts from a clean clone and installs dependencies itself — hence the node_modules stop. The setup script has a limit of roughly five minutes; the environment is cached as a snapshot and expires after about a week. The session survives that — it just resumes on a fresh VM.
• No vault for secrets. Environment variables can be read by anyone who uses the environment. I pick cloud tasks so they don't need tokens — hence tests of pure date logic, not something that touches an API.

When it makes sense, and when not

After one run I'm not making big claims, but a few things are already visible. Makes sense: a small, well-bounded task with no local state and no secrets — tests, documentation, an isolated refactor — and above all when I'm not at a computer. Typing the assignment on my phone took two minutes, and in the evening a finished branch was waiting. Doesn't make sense: anything that needs a local environment or tokens, and bigger changes I want to steer as they happen — the session would run on its own for a long time, and the final diff is too big a bite.

Parallel work on several tasks locally I handle differently — with git worktrees; a separate article on that is in the works. And there's a third variant, @claude in a GitHub PR via Actions — unlike cloud sessions, that one is billed through the API.

Conclusion

A small task went through the whole loop without a single intervention: assignment from the phone, sandbox, a reasoned unittest-vs-doctest decision, push to its own branch, teleport, green tests, merge. The review and the merge stay with me — the cloud doesn't even reach for them.

What I'm taking away: a good assignment is half the result (write down exactly what the tests should guard, and what's left open to decide), the sandbox installs everything from scratch, and teleport works reliably — it just wants its own terminal, and it's good to know it switches the branch. For tasks like "write tests for this", it's exactly right. Assign from the phone, merge at home.