A project folder I had been working on for weeks was gone. Not moved, not renamed — gone from the Desktop, with no trace in the obvious places. The kind of gone that produces a specific cold feeling in your stomach.
Here is how I got all of it back in under two minutes, and the mental model that made the panic unnecessary in the first place.
First, the thing that saves you: git is distributed
The single most important fact about recovering "lost" code is that with git, your local folder is not the canonical copy — it is a copy. If you ever pushed to a remote (GitHub, GitLab, a bare repo on a server), the full history lives there too, independent of your machine. Deleting the local folder deletes a checkout, not the project.
So the first move is never "panic" — it is "check the remote." If you can find the remote, you can git clone your way back to exactly where the last push left you.
The catch, and the reason people still lose work, is more mundane: you have to remember the project existed, what it was called, and where its remote is. When you are juggling a dozen side projects, a folder you deleted three weeks ago is easy to forget entirely. That is where the breadcrumbs come in.
The breadcrumbs: your tools remember more than you do
Modern AI coding tools keep per-project state on disk, and that state quietly encodes exactly what you need to reconstruct a lost project. Claude Code, for example, keeps a directory per project you have worked in, and it names those directories after the project's original absolute path, with the slashes turned into dashes:
~/.claude/projects/-Users-you-Desktop-super-gg-articles-gg
Read that back and it decodes cleanly to /Users/you/Desktop/super-gg/articles-gg. That one directory name told me three things I had forgotten: the project existed, its exact original location, and its name. Even after the source folder was deleted, this metadata survived — because it lives somewhere else entirely.
Inside those per-project directories you will often find more: session history, a memory or index file, sometimes transcripts of what you were doing. You are looking for anything that reminds you what the project was and where its code came from.
From breadcrumb to full recovery
Once I knew the project's name, finding its remote was a single command. The GitHub CLI can list every repo you own and filter by name:
gh repo list --limit 200 | grep -i "articles"
# hexcreator/articles.gg Invite-only markdown publishing platform private
There it was — a private repo, safe and complete, with every commit I had pushed. The recovery was the most boring command in the world:
git clone git@github.com:hexcreator/articles.gg.git ~/articles.gg
Two minutes after the cold-stomach feeling, I had the entire project back, tests and all. The "disaster" was a checkout I could recreate on demand.
What you actually lose (and what you don't)
Be precise about the boundary here, because it matters:
- Committed and pushed work: safe. It is on the remote. Deleting the local folder cannot touch it.
- Committed but not pushed: at risk. If those commits only ever existed in the deleted folder, they are gone with it — unless your OS trash or a backup (Time Machine, etc.) still holds the folder.
- Uncommitted changes: gone. Work you never committed lived only in that folder. This is the real lesson, and it points at a habit, not a recovery trick.
The mindset that makes this a non-event
The reason I could stay calm is that I had internalized one idea: your working copy is disposable. The canonical project is the remote plus your commit history; the folder on your Desktop is just today's convenient window into it. When you treat the local copy as disposable, two habits follow naturally:
- Commit and push often. Every push is a save point that survives your laptop. The smaller the gap between "I did work" and "it is on the remote," the smaller the blast radius of any accident.
- Trust the remote as home base. Cloning fresh should feel routine, not scary. If re-cloning a project feels like a big deal, that is a signal you are treating a fragile local copy as canonical.
The breadcrumbs in your tools' cache are a great safety net for the "which project was that again?" problem. But the real fix is upstream: push often enough that a deleted folder is, at worst, a two-minute inconvenience — and never a catastrophe.