You can hand development work to Claude Code cloud sessions without opening a new way into production, as long as the cloud can touch only one GitHub repository, and your production server only pulls from that repository. Getting there, though, I got stuck more than once. This article is my record (I run this site) of starting to use cloud sessions on a separate development project on October 4, 2026, rechecked against the original text of the official docs.
What the cloud can touch
One GitHub repository
Install the Claude GitHub App with "Only select repositories" and give it just this one repository.
Production server
Pull only
Production fetches the code with a read-only key. Neither the cloud nor GitHub gets a key to production.
Cloud environment
A fresh one per project
Anyone who uses an environment can read its environment variables. Keep secrets out of them.
Sources: Use Claude Code in the cloud and Configure cloud environments. Checked October 4, 2026. For how it works, how to get started and pricing, see "What Are Claude Code Cloud Sessions?"
Contents
1. A setup that protects production: production only pulls
My biggest worry was that going through GitHub would add another way into the production server. I settled on the setup below (this is my own choice, not an official recommendation). The arrows show the direction in which data is fetched.
- Cloud session Writes code and pushes branches (cannot get into production)
- →push
- Private GitHub repository The only repository the App is installed on
- ←fetch
- Production server Pulls with a read-only deploy key; a human runs the deploy
At first I tried to reuse a key from another repository, and GitHub rejected it with "Key is already in use." According to GitHub's docs, you see this when the key is already registered to another account or repository. Because each repository gets its own key, a leaked key exposes only that one repository.
2. What gets sent if you start without GitHub
I normally keep my code in a git repository on my own server, so at first I considered using cloud sessions without GitHub. According to the official docs, when you run claude --cloud "task description" in, for example, a repository with no remote, your local repository is packed into a single bundle and sent to the cloud. Here is what gets sent.
git add them if you need them).macOS, Linux, WSL
Secret-looking names stay local
For files named like .env, *.tfvars, id_rsa or *.pem, uncommitted changes are kept on your machine instead of being sent.
Windows (not WSL)
Sent regardless of name
Uncommitted changes to tracked files are sent as they are. Stash or revert any changes you don't want sent before you start.
The risky cases are when you track a file containing secrets in git and have edited it, and when you have committed secrets at some point in the past. A .env excluded by .gitignore isn't sent in the first place.
One more thing: according to the official docs, a session created from a bundle can push only to "repositories your GitHub connection has push access to." I couldn't find any way in the docs to send results straight back to a self-hosted, non-GitHub repository. After getting as far as writing a procedure document, I gave in and created a private repository on GitHub.
3. Five places I actually got stuck
Here are the snags I hit between creating a private repository on GitHub and actually getting started, each laid out as symptom, cause and fix.
1) The repository doesn't appear in the list
2) How widely to install the GitHub App
3) Repositories from organizations without the App show up
4) An old cloud environment was still there
5) I tried to have it read a local file
4. How permission modes differ in the cloud
Right before sending, I noticed the permission mode was set to "Accept edits." The name suggests it's the one that pushes ahead the most, but according to the official docs, Accept edits in the cloud corresponds to the default mode (Manual) in local Claude Code. In the cloud, file edits are pre-approved in every mode, so the default mode simply appears under this name.
Accept edits
Stops at commands
File edits go through automatically. Commands such as npm install, builds and git push wait for your approval each time.
Plan
Plans first
Before changing anything, it drafts and shows you a plan of what it will do.
Auto
Keeps going on its own
Instead of asking for approval, a classifier (a safety-checking mechanism) reviews each action and proceeds. It appears only when your organization allows it and the selected model supports it.
I wanted it to keep working without me, so I switched to Auto. Note that in the cloud you can't choose the mode that skips all checks (bypass permissions), and it's ignored even if it's set in the repository's settings file. For a detailed comparison of each mode, see "Claude Code Permission Modes."
5. What it actually cost: $226 from one instruction
With all that set up, I ran a cloud session on the Max plan's limited-time credit ($250). In the first message I handed over the design document and instructions, with the permission mode on Auto. After that, I never talked to it once. Partway through, I checked the usage screen, was startled by how fast it was draining, and told it to stop. When it stopped, I had $24 of credit left. Had I not stopped it, it would have burned through the whole $250.
$226
Credit used (of $250, $24 left)
676.7k
Context when stopped (68% of 1M)
86%
Plan's weekly limit used (all models)
Source: my Claude Code usage screen (October 4, 2026, Max 20x plan). The 86% of the weekly limit includes usage outside the cloud.
From one instruction, here is how much work the cloud had done by the time I stopped it (from my work log).
Why it drains so fast
Cost isn't driven by how many times you talk to it, but by how many times Claude calls the model and how much context it reads each time. When it runs autonomously, every file read, file write and test run triggers a call, so it can reach hundreds or thousands of calls without any conversation. The official docs (Manage costs effectively) also say that costs scale with context size.
Each call rereads the context so far. Even with caching, reads aren't free: at Opus 5.5's cache read price ($0.20 per million tokens), reading 500,000 tokens once costs about $0.10. Repeat that 1,000 times and it's about $100 (this is an example I calculated from the unit price; I haven't verified the actual number of calls or the model breakdown for this session). The code and tests it writes are counted separately at the output price.
As far as I could find in the official docs, there is no setting to cap credit spending (--max-budget-usd applies only to non-interactive runs, and the monthly spend limit is for pay-as-you-go usage credits). The only ways to set a stopping point are to write one into your instructions or stop it yourself. Also, once the credit runs out, cloud sessions run on your plan's weekly limit, just like local use. If you run a job of the same size when little of your weekly limit remains, you'll hit the limit, local Claude Code included.
The breakdown: rereading and subagents
After stopping, I opened the detailed breakdown on the usage screen (these figures cover the whole session, including the summary I had it write after stopping).
8h 33m
Time the model was working (I was hands-on for 2m 24s)
99%
Share on Opus (Sonnet 1%)
63%
Share from subagents (general-purpose 34%, Agent 29%)
Source: the session view of my Claude Code usage screen (October 4, 2026). Displayed cost: $231.09.
I was hands-on for only 2 minutes 24 seconds; for the remaining 8-plus hours, Claude was working on its own. Throughout that time, the main Opus conversation and the subagents, also running on Opus, were rereading an ever-longer conversation again and again. When I had the cloud session tally the breakdown, it reported that finishing one tool took about 30 actions for a Sonnet subagent and 130 to 230 actions for an Opus subagent (this is the session's own tally; I didn't check each one).
The cost shown on the screen ($231.09) was nearly the same as the drop in credit at the time I opened that screen ($250 → $18, or $232). I had $24 left when I stopped the session; I opened this screen afterward, so the balance had dropped a bit further by then. According to the official docs, the cost on this screen is an estimate based on token counts multiplied by list prices. So it seems safe to assume credit is deducted at API list prices (the official docs don't state this explicitly).
If you don't specify a model, subagents use the same model as the main conversation (official docs: "Create custom subagents"). With Opus as the main model, even bulk work ends up running on Opus.
Ways to cut costs (biggest impact first)
- 1. Run subagents on Sonnet Write "run subagents with model: sonnet" in your instructions. You can also change the default with the
CLAUDE_CODE_SUBAGENT_MODELenvironment variable (it isn't a secret, so it's fine to put in the environment). - 2. Keep conversations short (
/compactor a new session) The shorter the conversation, the cheaper each action. If you're staying on the same topic, summarizing with/compactshortens it without switching sessions (you can say what to keep, such as "keep the test results"). When the topic changes, or when you resume after a long pause, start a new session. If you have it write progress into a handoff document, nothing is lost when you break things up. - 3. Set a stopping point up front Write something like "stop and report once the foundation is done" or "stop and report at around $50" (there's no spending cap setting, so use instructions to set boundaries).
- 4. Delegate integration work too Let subagents handle testing, committing and pushing, so less work happens in the long, expensive main conversation.
- 5. Lighten verification Run UI tests only for the tools just built, and the full test suite once before merging. Take screenshots once per tool at desktop width and once at phone width.
- 6. Stop unneeded work right away A subagent stopped midway leaves no results behind, and what it used isn't refunded.
As a rule of thumb, run 2 to 3 in parallel. According to the cloud session's own assessment, reducing parallelism only stretches the time without changing the total cost much. What matters more than the number running in parallel is keeping each conversation short and each instruction specific.
Based on the official docs, here is how I think about choosing between /compact and a new session. /compact rereads the whole conversation to produce a summary, but while the cache is still warm, much of that reread comes from the cache, so it isn't as expensive as the conversation's size might suggest ("Prompt caching"). After a long idle period, once the cache has expired, the whole thing is reread without caching, which is costly. A new session, on the other hand, costs nothing but doesn't carry over what came before ("Manage costs effectively"). Summaries can drop details, so it's safer to have anything you want to keep written to a document first. Note that in cloud sessions /compact works but /clear doesn't; you start a new session from the sidebar ("Claude Code on the web").
Here is the kind of message I paste at the start of the next session (with the project name withheld).
Please resume from where you left off.
Read CLAUDE.md → docs/HANDOFF.md → docs/TODO.md and follow the rules.
Topic for this session: XX
Run subagents with model: sonnet, at most 2-3 in parallel.
Stop and report once you reach a budget of $XX. Report in English.For context summarization in cloud sessions, the cloud sets the CLAUDE_AUTOCOMPACT_PCT_OVERRIDE environment variable itself, so adding this variable to your environment has no effect. To make summarization kick in earlier, use CLAUDE_CODE_AUTO_COMPACT_WINDOW or /autocompact, as the official docs advise.
6. Checklist before you start
- GitHub account Is the account connected to claude.ai the one you want to use?
- App scope Did you install it only on the repositories you need, with "Only select repositories"?
- History Are there secrets you committed in the past still sitting in the repository's history?
- Environment Did you create a fresh one for this project? Are you keeping secrets out of its environment variables?
- Production Have you avoided creating any path from the cloud or GitHub into production (does production pull instead)?
- Rules Did you put the rules you reuse in the repository's CLAUDE.md?
- Permission mode Did you choose Auto to let it run, or Accept edits to check each step?
Summary
Using cloud sessions while protecting production comes down to three points: the cloud touches only one GitHub repository, production pulls from it with a read-only key, and a human runs the deploy. You can start without GitHub, but the repository is sent with the history of every branch, and on Windows, uncommitted changes to tracked files are sent regardless of their names.
Where I actually got stuck: a different GitHub account was connected, the App's scope, an old environment left behind, local files being invisible, and "Accept edits" stopping at every command. The checklist above prevents all of them.
On cost, a single instruction run autonomously used $226 of the limited-time credit before I told it to stop midway. Cost depends not on how many times you talk to it, but on the number of calls and the length of the context. In the breakdown, most of it came from rereading the conversation and from subagents running on the same model as the main conversation. Put subagents on Sonnet, keep conversations short with /compact or a new session, and write a stopping point into your instructions.
FAQ
Q. Can I try cloud sessions without GitHub?
A. Yes. claude --cloud "task description" bundles up and sends your local repository. It must be under 100MB and have at least one commit. The history of every branch is sent, and the official docs describe no way to send results straight back to a non-GitHub repository.
Q. Repositories from organizations where I didn't install the App show up in the list. Is something leaking?
A. Not if they're public repositories. When you connect through the GitHub App, cloud sessions can use all public repositories, so they appear as options. Private repositories are usable only where the App is installed.
Q. Is it okay to put an API key in an environment variable?
A. I don't recommend it. The official docs warn that anyone who uses an environment can read its environment variables, and advise against putting secrets there. On Pro and Max, you can instead register it under "API credentials," whose value the session can't read.
Q. I chose "Accept edits," but it stops at every command.
A. That's by design. In the cloud, edits are allowed in every mode, so the default mode appears under the name "Accept edits." To let commands run without approval, choose Auto (it appears only when your organization allows it and the model supports it).
Q. Why does credit drop so much when I'm not even talking to it?
A. Because cost is determined not by how many times you speak, but by how many times Claude calls the model and how much context it reads each time. When it runs autonomously, every file read, file write and test run triggers a call, and the context keeps growing. In my case, one instruction used $226 before I stopped it midway (section 5).
Q. Can the limited-time credit be used this way too?
A. Yes. The credit for Pro and Max (Pro $100, Max $250) is applied automatically to cloud session usage, and while it lasts, that usage doesn't count against your plan's usage limits. You can claim it until October 7, US Pacific Time, and it expires at the end of November 4 (4:59 PM on November 5, Japan time). It can't be used for Projects, Routines, Remote Control and so on. For details, see the official support article and "What Are Claude Code Cloud Sessions?"
Sources
- Claude Code official docs: Use Claude Code in the cloud (including the "Send local repositories without GitHub" section)
- Claude Code official docs: Get started with cloud sessions
- Claude Code official docs: Configure cloud environments
- Claude Code official docs: Permission modes
- Claude Code official docs: Manage costs effectively
- Claude Code official docs: Create custom subagents
- Claude Help Center: Cloud sessions bonus credit promotion
- GitHub Docs: Managing deploy keys and Error: Key already in use
All official specifications were checked against the original text on October 4, 2026. The setup record comes from a single run on a single project of mine, and what the screens show may change with versions and over time.
