Three Claude Code sessions deployed to geosearchconsole.co, my free tool site, between 2:10 and 2:30 PM on October 21, 2026, and two of the three deploys quietly undid the work of the one before. Every check each session ran came back clean.
I run several sessions at once, one per job. That afternoon one was updating the page for a new free tool, a Search Console data warehouse. One was fixing how the Rank Report reads Google’s results. One was adding a free SEO tools FAQ. Each session built a package of the whole site from its own copy, uploaded it, and extracted it over the live site. I build the site’s tools with Claude, so parallel sessions are how most of its work gets done.
What each Claude Code session shipped, minute by minute
What each Claude Code session shipped, minute by minute, comes from the three sessions’ release notes.
| Time (MT) | What happened |
|---|---|
| 1:55 PM | The FAQ session builds its package from the site as it stood then |
| 2:10 PM | The warehouse session puts a newer version of its page live |
| 2:14 PM | The Rank Report session deploys. Its package carries the earlier warehouse page, which goes back live |
| 2:24 PM | The FAQ session deploys the package it built at 1:55, putting back the old versions of the Rank Report session’s 9 files |
| 2:30 PM | One combined release goes live: the FAQ package, the newer warehouse page and the Rank Report fix |
For 16 minutes the warehouse page was its earlier version, and for 6 the Rank Report fix was undone. Nothing on the site broke outright that I know of. The damage was silent, which is the part that worries me.
Why a whole-site package undoes other work
A whole-site package undoes other work because it carries every file, not only the ones its session changed. Extracting it copies all of them over the live site, and as the GNU tar manual explains, tar replaces a file that already exists unless you tell it not to. So the Rank Report session’s package held its own changed files plus a copy of every other file as it stood when that session started, including a warehouse page from before the warehouse session’s update.
I use whole-site packages because one package is easy to verify and easy to roll back. They just assume nobody else shipped since you took your copy.
Why the checks stayed green
The checks stayed green because each one asked a narrower question than the one that mattered. The Rank Report session compared the live site’s file sizes against our shared copy of the site and would have stopped on any difference. The warehouse session had updated both the live page and the shared copy, so the two matched and nothing was flagged. The check asked “has someone changed the live site behind my back?” The question that mattered was “is my package about to put an older file back?”
The FAQ session’s miss was timing. It took its listing of the live files and uploaded its package at about 2:00, then spent about 25 minutes running test suites. Right before extracting, it reran a live check that looks for broken pages, not changed ones, and the check passed. In those 25 minutes the Rank Report session had shipped.
Every check passed, and the site was still wrong.
The check that caught it
The check that caught it was the plainest one: right before extracting, compare every live file with the package and stop on anything that differs outside your own release. The Rank Report session had a second package uploaded to fix the warehouse page, and that comparison showed the FAQ release had landed in the meantime, so the second package never went out. It rebuilt on top of what was live: the FAQ package byte for byte, the newer warehouse page, and its own files. Right before that extract, the only live files that differed from the package were its own 10 and one server settings file. Afterward, 74 of 74 live checks were clean, and the free SEO tools FAQ and the warehouse page were both the versions their sessions built.
It had happened once before
It had happened once before, on another of my sites, on September 29. Two sessions were working on it at the same time, one adding keywords and one fixing internal links. The keyword session’s package carried 81 files, and 41 of them were among the 43 the link session had just deployed. That time it was caught before the upload, and nothing went out. I made a rule from it, and on October 21 a session followed the letter of that rule and still missed: it checked before the upload, and the extract came 25 minutes later.
Separate checkouts didn’t protect the server
Separate checkouts didn’t protect the server, because the server was where the sessions met. Claude Code’s docs on parallel sessions suggest giving each session its own git worktree, a separate checkout on its own branch, so their edits don’t collide. My sessions never collided on disk. Each already worked in its own folder. They collided on the live site, where there is one copy and the last extract wins.
My rules for parallel Claude Code sessions now
My rules for parallel Claude Code sessions now are short, and every session that deploys to that site follows them.
- Before deploying, look for any other session working on the same site, and agree on which one ships.
- Right before the extract, not the upload, compare every live file with the package. Anything changed outside your own release means someone else shipped, so rebuild on top of theirs.
- Once the live checks pass, copy what you shipped into the shared copy at once, so the next session builds on it.
The second rule is the one that would have saved the afternoon. Three deploys in 20 minutes is rare for a small site run by people. With sessions working in parallel it was an ordinary Wednesday, and a check built for one deploy at a time can’t see the others.
Sources
- Common workflows: Run parallel sessions with worktrees (Claude Code Docs)
- Dealing with Old Files (GNU tar manual)
- Free SEO Tools FAQ (GEO Search Console)
- Search Console Data Warehouse (GEO Search Console)