# What I Learned From My First Claude Code Cloud Sessions
> Source:
> Published: 2026-10-15 06:30:00+00:00
AI
# What I Learned From My First Claude Code Cloud Sessions
I built a Laravel app in Claude Code cloud sessions with a $250 credit. What worked, what broke, and why I still prefer my laptop.
## how to use AI series
- 1 [AI Code Hallucinations: When Your AI Writes Confident Nonsense](https://albertoarena.it/posts/ai-hallucination-in-coding-agents/)
- 2 [We Became Editors-in-Chief, and Nobody Trained Us](https://albertoarena.it/posts/we-became-editors-in-chief/)
- 3 [Claude Code Auto Mode: What Still Needs a Human](https://albertoarena.it/posts/claude-code-auto-mode-still-needs-a-human/)
- 4 [Context Engineering: The Discipline That Keeps AI From Writing Slop](https://albertoarena.it/posts/context-engineering-not-slop/)
- 5 [Agent Teams: Why I Don't Let My Reviewer See My Reasoning](https://albertoarena.it/posts/agent-teams-isolated-reviewer/)
- 6 [I told Claude not to sign my commits. It signed 25 of them.](https://albertoarena.it/posts/i-told-claude-not-to-sign-my-commits/)
- 7 [The Effort Was the Filter](https://albertoarena.it/posts/the-effort-was-the-filter/)
- 8 [The Sound of Silence: What Your AI Agent Does Not Tell You](https://albertoarena.it/posts/the-sound-of-silence/)
- 9 What I Learned From My First Claude Code Cloud Sessions
[View series →](https://albertoarena.it/series/how-to-use-ai/)
I got $250 of free credit for Claude Code in the cloud. I had used the Claude Code app a few times, but never the way I tried now: from the terminal, with `claude --cloud`. So I took a real project and built it that way, one milestone at a time. The project is [Sudo Play](https://github.com/albertoarena/sudo-play), a small macOS menu bar app I built with Laravel and NativePHP. I understood very little about how cloud sessions work when I started, so this is mostly what I found out by doing it.
## Two Claudes, and me in the middle
I used two Claudes. The first one runs on my laptop. For each milestone it writes a brief: what to read first, the branch name, the scope, the tests to write, and what not to touch. Later it reviews the result. The second one runs in the cloud, in a Linux container. It reads the brief, writes the code test first, opens a pull request and stops. I start each session, carry the result back, and merge. Nothing was merged without me.
There is one limit. From your terminal you can send a message to a cloud session, but you cannot read its reply. So I copied the final report from claude.ai and pasted it into my local session. It is not elegant, but it works. It is also the idea behind an [isolated reviewer](https://albertoarena.it/posts/agent-teams-isolated-reviewer/): the agent that wrote the code should not be the one that judges it.
## The command that stopped working
My briefs are markdown files, and the last section is called `## The prompt`. At first I launched each session with the brief as a second argument:
```
claude --cloud "Sudo Play: M5" "$(sed -n '/^## The prompt$/,$p' .docs/M5-BRIEF.md | tail -n +3)"
```
Then Claude Code 2.1.287 changed it. The `--cloud` flag now takes one argument, and the second one is dropped with no error. I checked with `claude --help`, which shows `--cloud [description|session_id|url]`. Two of my sessions started with only the title. One of them built a whole pull request without ever seeing its brief.
Now it takes two commands. The first creates the session, and it needs a real terminal:
```
claude --cloud "Sudo Play: M5"
```
The second sends the brief to that session, using its id. It can run from anywhere, including from my local Claude:
```
claude -p "$(sed -n '/^## The prompt$/,$p' .docs/M5-BRIEF.md | tail -n +3)" --cloud
```
After the lost brief, I changed the first line of every brief. It now asks the session to repeat the branch name before doing anything else. If the brief got lost, I see it in the first reply.
## The PHP version nobody listened to
The container had PHP 8.3, and my project needs 8.4. I wrote in the brief, in plain words, that 8.4 cannot be installed there, and I listed what had already failed. Three sessions in a row tried anyway. I was not happy about that.
The rules in `AGENTS.md` were different. They held every time. Never merge your own pull request. Stop and ask when the plan and the requirements disagree. No session broke one of them.
I think it is about placement, but this is a guess. A brief is read once, along with everything else in it. `AGENTS.md` is read first, and it sounds like the project talking. After the PHP episode, I started moving any rule that a brief could not enforce into the committed rules.
The “stop and ask” rule gave me the best moment of the project. One session tested the plan’s rotation algorithm over 400 days and found that it repeated the previous day’s pick 42% of the time. It stopped and asked how the rule should change. It did not build something that only passed the tests.
## When the tests were green and the app was wrong
Twice the tests passed and the app was still wrong. One bug only appeared when I pressed Play with Spotify closed. Every test faked Spotify, so no test could see it. After that I ran each branch on my Mac before merging, at least when it touched windows, timing or the operating system. When I found a bug, the cheapest fix was one more message to the same session. I wrote what I saw, the test that should fail first, and “push to the same branch, no new PR”. The session still had all its context.
## The footer that came back
Every pull request description ended with a “Generated by Claude” line. My `AGENTS.md` says clearly not to add it, and it was there every time. I was definitely not happy about that one. It also confirmed my habit of double checking every pull request.
Nothing inside the session removed it. One session sent the description with plain `curl` instead of `gh`, and the line was still there. Editing the description from inside the session brought it back too. A few sessions even added a note asking me to remove the line, so I had two things to delete.
What worked was editing the description from my own machine, with `gh pr edit --body-file` or on the GitHub page. I do not know why the line appears. I had [the same fight with commit trailers](https://albertoarena.it/posts/i-told-claude-not-to-sign-my-commits/) before, so at least it was a familiar one.
## The same four problems, every session
Every Laravel session hit the same four problems and solved them again from zero. Composer complained because the container runs as root, so it needed `COMPOSER_ALLOW_SUPERUSER=1`. PHPStan would not download, so it was built from its git tag. The page tests failed without a Vite manifest until `npm run build` ran before Pest. PHPStan also ran out of memory until it got 2G. Each one cost a few minutes, and I paid for them every time, because I had put them in the briefs and not anywhere permanent.
## Would I keep using it?
I am not sure what I will do when the credit ends. I still prefer Claude Code on my laptop. It is cheaper for me, because I already pay for Claude Max.
But cloud sessions are useful when I am away from my desk. I can start a milestone, close the laptop, and read the pull request later.
## If you try it
- Create the session first, then send the brief with a second command.
- Make the first line of the brief ask for the branch name, so a lost brief shows up at once.
- Put lasting rules in `AGENTS.md` , not in the brief.
- Run the branch on the real machine before you merge, not only the tests.
- Edit the pull request description from your own machine, and plan for one edit per pull request.
- Put the Laravel workarounds in `AGENTS.md` or in the environment’s setup script.