# Claude Code desktop and remote: cloud sessions, SSH, diff review, auto-fix PRs > [!summary] TL;DR > Claude Code can run on a machine that is not yours: a cloud VM session (roughly 4 vCPU / 16 GB / 30 GB, ephemeral), an SSH session into your own workspace, or the desktop app. The whole `.claude/` setup (`CLAUDE.md`, rules, skills, allowlist) carries over unchanged. The desktop diff panel accepts queued inline comments, and a PR-watching agent can fix CI failures and reviewer comments by itself. You still press the merge button. ## Key points - Cloud VM sessions run in a roughly 4 vCPU / 16 GB / 30 GB box that Anthropic spins up per session; the docs call the ceilings approximate and reserve the right to change them. - The cloud box is ephemeral: the repo is cloned fresh when the session starts, the container is reclaimed when the session ends, and anything worth keeping must be committed and pushed first. - `CLAUDE.md`, `.claude/rules/`, the allowlist in `settings.json`, and skills under `.claude/skills/` load in cloud and SSH sessions the same way they load when you run `claude` in your own terminal. - Per the cloud-sessions docs table, `CLAUDE.md`, skills, agents, commands, and rules all carry, and so do MCP servers declared in the repo's `.mcp.json`; user-config MCP servers (`claude mcp add`, `~/.claude/*`) do not. - The mobile app pokes you when a session needs an answer or a permission prompt, so you can close the lid. - Tasks that need local tooling, local secrets, or a local model server stay on the laptop or move to the workspace; bug fixes and small refactors go to the cloud. - Anything that touches the build cache, talks to a local model server, or expects `pyenv` to already have Python 3.11.7 installed goes to the SSH workspace. - The diff panel lets you click any line in a hunk and leave a comment, the same way you would on a pull request; comments queue and go with your next message. - A PR-watching agent picks up CI failures (reads the logs, tries a fix, pushes a new commit) and reviewer comments (replies with the diff), but it does not merge. - If the agent has tried three pushes on the same failure and CI is still red, the loop has stalled and the next move is yours. - Voice prompts work in the desktop app but are one-shot: you must know the whole prompt before you start speaking. - Cloud sessions are the more expensive option; pick them when they earn it (lid closed, ephemeral environment, easy task), not by default. ## Cloud sessions: run the session on a machine that is not mine Cloud VM sessions run in a roughly 4 vCPU / 16 GB / 30 GB box that Anthropic spins up per session; the docs call the ceilings approximate and reserve the right to change them. The box is ephemeral. The repo is cloned fresh when the session starts and the container is reclaimed when the session ends; anything worth keeping has to be committed and pushed first. The habit: when a task is well-defined enough to write in three lines (fix these bugs, rerun the migration, bump this dependency and update the call sites), push it to a cloud session instead of running it on the laptop. The cloud session does not care that you closed the lid, does not stall when the battery dies on the train, and is not squatting in the terminal you are using for something else. When it needs you, the mobile app pokes you. The friction this removes is not "I can do more work in parallel." It is that you stop being the rate-limiting hardware. Past me queued tasks behind whatever the laptop was already doing; present me does not. ## What carries over from a local setup The setup transfers. Same agent, different chrome, different hardware behind it. If you have already done the work of writing a `.claude/` directory at the repo root, the desktop app carries all of it forward. The cloud-sessions docs publish an explicit table of what is and is not available: `CLAUDE.md`, skills, agents, commands, and rules all carry, and so do MCP servers declared in the repo's `.mcp.json`. User-config MCP servers (`claude mcp add`, `~/.claude/*`) do not. ## SSH sessions into the workspace The desktop app also speaks SSH: point it at a remote machine and the session runs there instead of in an Anthropic-managed VM. The SSH session shows up in the same desktop UI as the cloud one: diff panel, review queue, permissions prompts, all the same chrome over a session that happens to be running fifty miles away. The shape that keeps working: tasks that need a real environment get an SSH session, tasks that need clean isolation get a cloud session. The dev workspace is a small machine that holds the build caches, the model weights, and the toolchains that take half an hour to install fresh. Cloud VM sessions cannot use any of that. SSH sessions can. ## Diff view and inline comments as the review loop The desktop app puts the agent's pending diff in a panel. You can click any line in a hunk and leave a comment, the same way you would on a pull request. The comments queue, and the next time you send a message the queued comments go with it. Comments left in one pass on a real diff: - "Move this guard into the existing `validate()` function." - "Stop renaming the variable, the old name is referenced from `docs/`." - "This loop should early-exit on the first match." Then one short message: "apply the comments, ask if anything is ambiguous," and the agent works through them. Why this matters: you were reading the diff anyway. The cost of leaving a comment on hunk three while looking at hunk five is lower than holding three things in your head until the end, and the agent gets the comments grouped with the spatial context, which is the form they make most sense in. The single rule here: do not leave a comment you are not willing to defend. The agent will do what the comment says. If the comment was lazy, the change will be too. ## Let the PR fix itself When the desktop app opens a pull request, it can subscribe to the PR's GitHub events. CI runs and fails; the agent picks up the failure, reads the logs, tries a fix, pushes a new commit. A reviewer leaves a comment; the agent reads the comment, tries an interpretation, replies with the diff. Both of those used to be context switches that landed on you. The setup is one prompt at the end of the session: "open a PR for this branch and watch it." The agent posts the PR, subscribes to the events, and the session keeps running in the background. The status you come back to reads like this: "the PR is open, CI was red, here is the fix, CI is green, the reviewer left two comments, here are the responses." I do not let it merge. The agent watches the PR; I still press the button. The autonomy I want is the loop closing on the obvious things: lint failure, test flake, a reviewer asking for a one-line rename. Deciding whether the change is the right change stays with me. The auto-fix is a labor-saver, not an oracle. ## Voice prompts and cost Voice works. I cannot find official docs for it, but the desktop app accepts spoken prompts and they land as text on the prompt line. The caveat is that the prompt is one-shot: no "wait, also" mid-sentence, no back-and-forth while you frame what you actually meant. You have to know the whole prompt before you start saying it. That flips voice from useful to annoying for anything that needs structure; half of my prompts get written in two passes, the first of which is "what do I actually want to ask." Reach for voice on short prompts ("run the tests") and not for structured ones. The other rough edge: cloud sessions cost something. The docs are clear about resource limits, quieter about how to budget them across a day. I have not bumped a quota, but I also do not know where the line is. I treat cloud sessions as the more expensive option and pick them when they earn it (lid closed, ephemeral environment, easy task), not by default. ## What still applies from the terminal habits - Plan mode still applies, and it matters more here. On the laptop you can catch a bad plan quickly because you are standing over its shoulder. In a cloud session the machine keeps working through the bad plan until you check on it, which turns a bad plan into as much time as you leave it running. - Fresh sessions still apply. The cloud VM is literally a fresh machine each time; the `.claude/` directory committed to the repo is what re-establishes context, exactly as at the start of every local session. - The on-disk canon (`PROGRESS.md`, `TODO.md`, `CLAUDE.md`) matters more, not less. When the session can fork onto a remote box you cannot see, the only state to trust is the state that survives the session ending. Disk is still the canon; chat is scratch. An example run: three small bugs to fix on `af` before lunch, the laptop about to be in a meeting. Open the desktop app, point a cloud session at the repo, give it the three bugs from `TODO.md`, close the lid. After the meeting there is a PR open with green CI; queue two comments in the review panel; the PR comes back fixed. Part 5 is probably about subagents: the Explore, Plan, and general-purpose agents that run inside a session in their own worktrees, in parallel. I have been running three or four at once on bigger refactors. ## FAQ ### Do CLAUDE.md and skills work in Claude Code cloud sessions? Yes. `CLAUDE.md`, `.claude/rules/`, the allowlist in `settings.json`, and skills under `.claude/skills/` load in cloud and SSH sessions the same way as in a local terminal. MCP servers declared in the repo's `.mcp.json` also carry; user-config MCP servers (`claude mcp add`, `~/.claude/*`) do not. ### How much hardware does a Claude Code cloud session get? Roughly 4 vCPU / 16 GB / 30 GB per session. The docs call the ceilings approximate and reserve the right to change them. The box is ephemeral: the repo is cloned fresh at session start and the container is reclaimed at session end, so commit and push anything worth keeping. ### When should I use an SSH session instead of a cloud session? Use SSH when the task needs a real environment: build caches, model weights, toolchains that take half an hour to install fresh, or a local model server. Use a cloud session for clean isolation, bug fixes, and small refactors. ### Can Claude Code fix its own pull request? Yes. The desktop app can subscribe to a PR's GitHub events: on a CI failure the agent reads the logs, tries a fix, and pushes a new commit; on a reviewer comment it replies with the diff. It does not merge; you still press the button. ### When do I take over from an auto-fix loop? If the agent has tried three pushes on the same failure and CI is still red, the loop has stalled and the next move is yours. The auto-fix is a labor-saver, not an oracle. ### Does voice input work in the Claude Code desktop app? Yes, spoken prompts land as text on the prompt line, but the author cannot find official docs for it. The prompt is one-shot: you must know the whole prompt before you start saying it. ### Do cloud sessions cost more than local sessions? Cloud sessions cost something; the docs state resource limits but not how to budget them across a day. Treat them as the more expensive option and pick them when they earn it: lid closed, ephemeral environment, easy task. ## Related - [[resources/documentation/Agents/Agents Workflow|Agents Workflow]] (series hub) - [[resources/documentation/Agents/Agents - Plan First, Fresh Sessions, Write It Down|Plan First, Fresh Sessions, Write It Down]] (Part 1: plan mode, fresh sessions, the on-disk canon) - [[resources/documentation/Agents/Agents - One Workstream per Task|One Workstream per Task]] (Part 2: one workstream per task) - [[resources/documentation/Agents/Agents - One Memory, Many Harnesses|One Memory, Many Harnesses]] (Part 3: one memory shared across Claude Code and pi) - [[resources/documentation/Claude Focus Workflow|Claude Focus Workflow]] (related workflow) ## Sources - [Claude Code on the web (cloud sessions and auto-fix pull requests)](https://code.claude.com/docs/en/claude-code-on-the-web/) - [Claude Code on the web, auto-fix pull requests](https://code.claude.com/docs/en/claude-code-on-the-web/#auto-fix-pull-requests) - [Claude Code Desktop app](https://code.claude.com/docs/en/desktop) - [Permission modes, plan mode](https://code.claude.com/docs/en/permission-modes) - [Subagents](https://code.claude.com/docs/en/sub-agents) - [Worktrees](https://code.claude.com/docs/en/worktrees) - [pi](https://pi.dev)