One Project, Too Many Sessions: Keeping Track of AI-Assistant Work Across Devices

IT Hands Free — practical notes from our own workbench

AI coding assistants like Claude are genuinely good now. Over the last couple of weeks one helped us rebuild large parts of this very website — the Cloud PBX pages, a Fanvil phone catalogue, an estimator that emails a branded PDF quote, and this blog. It moved fast and the work was solid.

Then we nearly lost a chunk of it. Not because the AI did anything wrong, but because we spread the work across too many sessions and devices without a single place that held the truth. If you use these tools across your web browser, the desktop app, and more than one computer, this post is the mistake we made so you do not have to.

The short version

• Every AI session starts with no memory of the others. It only knows what is in the files in front of it right now.
• Work done in different sessions can land in different places — separate git branches, or an uncommitted "working copy" on one machine — and none of them is automatically the master.
• Deploying the wrong copy, or a partial backup, is then easy: we overwrote part of our live site and briefly lost the blog.
• You will move a job between the local assistant — the one that can open your files, build, and deploy — and the cloud chat that follows you across devices. That is a good thing, as long as both hand off through one central store like GitHub.
• The fix is not clever. It is one home for the project, commit-and-push every session, and a way to see exactly what is live.

What actually happened

The website is really three pieces: the public site (the frontend), a small email/quote service (the backend), and this blog (a separate little app). Over several sessions — some on the desktop app, some in a browser, across two machines — each piece got worked on.

The trouble crept in quietly:

• The blog's newest version (with an RSS feed for auto-posting) had been built in one session and pushed to a branch on GitHub. Our local "master" copy and our backups were older and did not have it.
• The newest quote-engine work lived only in a temporary working folder and in the zip files we had downloaded — it had not been committed anywhere permanent.
• When we redeployed the site, the upload replaced the live folder, and the blog — which was never in that particular package — disappeared.
• And the honest question we could not answer quickly: which version is actually live right now? We had several zips named like "latest backup," built at different times, and no way to tell them apart at a glance.

Nobody did anything careless. It was just entropy: many good sessions, no single source of truth.

Why this happens with AI assistants specifically

A human colleague remembers yesterday. An AI session does not. Each new session is a blank slate — it reads the files you give it and works from those. That is a feature, not a bug, but it has consequences:

• If two sessions touch the same project, neither knows what the other did unless it is written into the shared files.
• The assistant will happily create a new branch, or work in a fresh copy, to keep things tidy on its end — which is sensible per-session but leaves you with pieces in several places.
• Switching devices (desktop → web, laptop → office PC) makes it worse: now the "current" files differ per machine, and the assistant on each one only sees its own.

None of this is dangerous if everything flows back to one place after each session. The danger is treating each session's output as finished and moving on.

Local muscle, cloud reach — and why GitHub sits between them

There are really two ways to work with an assistant like Claude, and they are good at different things.

• The local assistant — Claude Code, or the desktop app given access to your Windows folders — runs on your machine. It can open your real files, run a build, commit to git, and push a deploy. When the work is hands-on — writing code, wiring services together, fixing what is actually on disk — this is where the heavy lifting happens.
• The cloud chat — the web or mobile app — goes everywhere you do and is ideal for thinking, drafting, and planning. But it works with what you bring into the conversation, not the files sitting on your office PC.

Neither is "better," and a real project moves between them: sketch the plan in the cloud on your phone, then do the build-and-deploy on the machine that can actually reach the files. The catch is the handoff. If the local session's work stays on that one PC, and the cloud session's work stays in that one chat, you end up with two half-finished versions and no master copy — which is more or less how we lost track of our own blog.

This is exactly what GitHub is for. It is a central store that both kinds of session can reach — not tied to one computer, and not tied to one conversation or the assistant's own cloud. The local session pushes its work up; the next session, wherever and however it starts, pulls it down and can see where things left off. Your work stops living inside a session and starts living somewhere the sessions simply visit.

That is the shift that quietly fixes everything else: choose local when you need to touch real files, choose the cloud when you need reach and portability — but have both come home to the same repository every time.

The four ways it bites you

1. Scattered work — the newest version of each piece is on a different branch, machine, or download folder.
2. "Which one is live?" — several backups, all plausibly "latest," and no reliable marker on the running site.
3. Partial backups — you save the piece you changed today and assume it is the whole project. (A source-code backup is also not a runnable website — a distinction that surprised us mid-recovery.)
4. Overwriting the innocent — deploying one component wipes another that shared the same folder, because the deploy package only contained the part you were thinking about.

How we keep it straight now

None of this needs special tools. It needs a few habits:

1. One home for the project. Pick a single git repository — GitHub works well — as the master. Every session, local or cloud and whatever device it is on, starts by pulling from there and ends by pushing back to it. It is the one thing that lets you swap between the local assistant and the cloud chat without dropping the thread. If it is not in the repo, it does not exist.

2. Commit and push at the end of every session. Do not leave work in an uncommitted "working copy." An uncommitted change is invisible to your other devices and to your backups. Commit it, push it, and the next session — anywhere — can pick it up. Merge any session branches back into your main line quickly, before they drift.

3. Prefer to continue one session per project when you can. If you are actively working a project, resuming the same conversation keeps the context intact and avoids the "fresh blank slate" reset. When you do need to switch devices, hand off through the repository — not through memory, and not through a pile of loose zip files.

4. Put a version marker on the live thing. We now stamp the deployed site with a small version.txt that records the version, build time, and exact code revision — including a flag if it was built from an uncommitted copy. One command tells us what is really running:

curl https://ithandsfree.com/version.txt

Paired with a plain CHANGELOG.md in the repo, we can always answer "is the right version live?" in ten seconds.

5. Back up the whole project, and know source from servable. Back up every component together, not just today's piece. And keep clear which package is the editable source and which is the built, deployable copy — they are not interchangeable, and reaching for the wrong one during an outage costs you time you do not have.

6. Deploy without clobbering the neighbours. If a site has separate parts sharing one folder, make each deployment either contain everything or touch only its own files — never a blind "delete all, upload my part."

So — one session, or many? Local, or cloud?

Our honest recommendation: many sessions are fine; many sources of truth are not. Use whatever is in front of you — desktop or web, the local assistant or the cloud chat, this laptop or the office PC. Start fresh sessions when it helps, and move the job to the local tool when it needs to touch real files. Just make the git repository — not any single session, tool, or machine — the thing that remembers. Sessions are conversations; the repo is the record.

The bottom line

The AI did the work well. What tripped us up was ordinary project hygiene, made a little sharper by tools that forget between conversations. Keep one repository as the master, commit and push every time, mark what is live, and back up the whole project — and you get all the speed of an AI assistant with none of the "wait, where did that version go?"

If your firm is starting to lean on AI tools for real work and you want a sane way to keep track of it — versioning, backups, and a single source of truth — that is squarely the kind of thing we help clients set up. It is a good problem to solve before the week you nearly lose.