I was scrolling through the sabine-super-agent repository today when I noticed something that made me pause: current_sabine_inbox.json. A file I'd completely forgotten about. One git show later, I was staring at ten of my actual emails from January, complete with subjects, snippets, and thread IDs.
Not production secrets. Not API keys. Just debugging artifacts that had slipped through during early development—the kind of file you generate when you're testing email parsing, then forget to .gitignore. Four different email snapshot files, actually, dating back months. And nestled alongside them: the supabase/.temp/ directory, a Supabase CLI cache folder full of project identifiers, version strings, and a database connection URL.
Nothing was exploitable. The emails were test messages I'd sent myself. The Supabase identifiers were already in environment variables elsewhere. But the principle violation was clear: this is a public repository. Personal data and infrastructure identifiers don't belong in commit history, even if they're not directly exploitable.
What Changed
The fix was straightforward. I removed the files from the index with git rm, added .gitignore entries for both the email snapshots and supabase/.temp/, and committed the changes. The files are gone from the working tree. They'll never be committed again.
Here's what didn't change: git history. Those files are still in past commits, visible to anyone who knows how to use git log. Scrubbing history is possible—git filter-repo can rewrite commits and remove files retroactively—but it's a destructive operation that rewrites commit hashes and breaks any existing references. For a solo project with no external dependencies, that might be acceptable. But for now, I'm treating this as a learning moment rather than an emergency.
Why It Matters
This is the kind of mistake that's easy to make when you're building fast. You generate a debug artifact to test something. It sits in your working directory. You forget to .gitignore it. Eventually, you commit everything with a broad git add. By the time you notice, it's three months later and buried under dozens of subsequent commits.
The lesson isn't 'be more careful.' The lesson is: build .gitignore patterns preemptively. If you're generating JSON snapshots for any reason, ignore *.json in your root directory unless you explicitly need specific files tracked. If you're using CLI tools that create cache directories, ignore those directories by convention before you ever run the tool. Defensive version control isn't paranoia—it's just recognizing that your future self will be too busy building to remember what should and shouldn't be committed.
What's Next
I'm watching the repo for a week to see if anything breaks. If the historical commits cause issues—or if I find other artifacts that need removal—I'll revisit the question of rewriting history. For now, the working tree is clean, future commits are protected, and the incident is documented.
Sometimes the best code you write is the code you delete. And sometimes the most important .gitignore entry is the one you add after you realize what you should have ignored all along.