I got tired of saying "it worked yesterday" so I built a CLI to prove it

Akshit Chugh — Tue, 02 Jun 2026 11:57:12 +0000

Last month I was debugging a Prisma issue for like two hours.

Everything was fine the day before. Same code. Same machine. I hadn't touched the project in a few days, came back, ran it boom, crash. PrismaClientInitializationError. I checked the schema. I checked the database. I regenerated the client. Nothing.

Turns out I had updated some global packages a couple days earlier and Prisma's CLI version had drifted out of sync with what the project expected. Two hours of my life. Gone. For a version number.

And the worst part? I couldn't even be sure that was the actual cause. I was just guessing.

That's the thing nobody talks about. Your environment is silently mutating all the time. You npm install -g something here, your Node version bumps there via nvm, a port that used to be free is now occupied — and you have zero record of any of it. When something breaks, you're doing archaeology with no tools.

So I spent a day and built snapcd.

What it does

Every time you cd into a project directory, it silently takes a snapshot of your environment in the background. We're talking:

Node + npm versions
All globally installed packages and their versions
Environment variables (sensitive ones like SECRET, TOKEN, KEY get auto-redacted)
PATH entries
Open ports
Hostname, platform, CWD

Under 100ms. You won't even notice it's running. Same trick nvm and direnv use.

Then when something breaks, you just run:

snapback diff

And you get a clean diff of exactly what changed between your last two snapshots.

Snapback diff: "before-upgrade" → "after-upgrade"

Core
  ✅ Node.js : v20.11.0
  ⚠️  npm     : 9.8.1 → 10.2.4

Global npm Packages
  typescript   ⚠️ changed   4.9.5 → 5.3.2
  vercel       ✚ added      33.0.0
  netlify-cli  ✗ removed    17.0.0

Open Ports
  ✚ 3000
  ✗ 8080

If I'd had this during the Prisma incident, I would've seen prisma sitting right there with a version change and fixed it in five minutes.

How to use it

npm install -g snapcd

Add the shell hook to your .zshrc or .bashrc:

eval "$(snapback hook)"

That's it. From now on every cd auto-snapshots silently. You can also save manual named snapshots before doing something risky:

snapback save before-that-upgrade
# do the thing
snapback save after-that-upgrade
snapback diff before-that-upgrade after-that-upgrade

Everything is stored locally in ~/.snapback/<project-name>/snapshots.json. No account, no cloud, no telemetry.

Why I built it in a day

Honestly I didn't want to over-engineer it. The whole point is that it should be invisible until you need it. I wrote it in Node.js, kept the output readable, and shipped it.

There's a certain class of bugs that aren't really bugs — they're just your environment silently changing underneath you. snapcd doesn't fix those bugs. It just makes sure you're never blind when they happen.

If you've ever said "it worked yesterday" and meant it, give it a try.

GitHub: github.com/achugh787/snapcd

Docs: achugh787.github.io/snapcd

Curious what you think. Would love feedback on what else it should track.

DEV Community: Akshit Chugh

I got tired of saying "it worked yesterday" so I built a CLI to prove it

What it does

How to use it

Why I built it in a day