I Forgot Which AI Tool Built My Project - So I Investigated Like a Detective

A few days ago I had a small panic moment that I think a lot of developers juggling multiple AI coding tools will recognize. I'm building a membership and matchday platform for Mugutha FC, a community football club in Ruiru, Kenya playing in the Mt. Kenya Regional League. Somewhere in the blur of late-night builds across different AI assistants, I lost track of where one specific version of the dashboard actually lived on my machine. I had a screenshot. I had a vague memory of a localhost URL. That's it. Here's how I found it - and the small forensic trick that cracked it open.

The clue I had

The only solid evidence was a screenshot of the dashboard running in my browser:

• URL bar: 127.0.0.1:5173
• A timestamp visible in the Windows taskbar clock: 6/25/2026, 12:09 AM
• Sidebar items: Dashboard, Members, Fixtures, Broadcasts, Templates, Analytics, Settings
• A "Welcome, Wakili Eric" greeting and KPI cards for Active Members, Messages Sent, Fixtures This Month, and Expiring Soon

Port 5173 was the first real clue. That's Vite's default dev server port - so whatever this was, it was a React or Vue project scaffolded with Vite, running locally, not deployed anywhere. But which folder? I have a habit of spinning up project folders across different AI coding assistants while comparing approaches, and frankly I'd lost track of which tool had generated which version.

Turning a screenshot into a search query

The breakthrough was realizing the timestamp in the screenshot wasn't just a "nice to have" - it was a search filter. Windows has a built-in command called forfiles that can filter files by modification date. Combined with a recursive search and a keyword filter, I could ask Windows: "show me every project file touched on or after this exact date."

First attempt - search by filename:

forfiles /P "C:\Users\%USERNAME%" /S /M *mugutha* /D +0 /C "cmd /c echo @path @fdate @ftime" 2>nul

This searches for any file with "mugutha" in the name. It's a reasonable first guess, but it has an obvious flaw - it only works if the folder itself was named with "mugutha" in it. If an AI tool had scaffolded the project into something generic like dashboard-app or a sandboxed temp folder, this search would find nothing.

So I pivoted to searching by what a Vite project actually contains, rather than what it's named:

forfiles /P "C:\Users" /S /D +06/24/2026 /C "cmd /c echo @path @fdate @ftime" 2>nul | findstr /I "package.json vite.config"

Breaking that down:

• /P "C:\Users" - start the search at the Users directory
• /S - search recursively, including all subfolders
• /D +06/24/2026 - only files modified on or after this date
• /C "cmd /c echo @path @fdate @ftime" - for every match, print its full path, date, and time
• findstr /I "package.json vite.config" - pipe the results through a filter that only keeps lines mentioning package.json or vite.config, the two files that exist in basically every Vite project root

This is the key idea: instead of guessing a project name, I searched for the fingerprint of the technology - files that are guaranteed to exist if a Vite project exists, regardless of what anyone called the folder.

What came back

The output was immediately interesting:

"C:\Users\CodexSandboxOffline\.codex\.sandbox\cwd\c01195b0e0a02dfa\package.json" 6/24/2026 8:22:03 PM
"C:\Users\CodexSandboxOffline\.codex\.sandbox\cwd\c01195b0e0a02dfa\node_modules\.vite\deps\package.json" ...
"C:\Users\CodexSandboxOffline\.codex\.sandbox\cwd\c01195b0e0a02dfa\node_modules\@vitejs\plugin-react\package.json" ...

And there it was. Not in any of my normal project folders. Not in Desktop\projects\Mugutha_MembersClub. It was sitting inside a completely separate Windows user profile: CodexSandboxOffline. That folder name told me everything. This particular version of the dashboard hadn't been hand-built by me in a normal project directory - it had been generated and run inside an isolated sandbox environment created by OpenAI Codex, complete with its own user account, its own node_modules, and a dependency tree showing @vitejs/plugin-react, lightningcss, rolldown, and lucide-react - a modern, fast Vite + React toolchain.

Mystery solved. The dashboard in my screenshot wasn't from a different session of the same tool I'd been using elsewhere - it was a different AI assistant entirely, sandboxed in its own corner of the filesystem the whole time.

The actual lesson here

The interesting part of this story isn't really about Codex or sandboxes specifically. It's a pattern worth remembering if you work across multiple AI coding tools:

• A screenshot timestamp is a search filter, not just a memory aid. Once I treated the clock in the corner of my screenshot as a literal date filter for forfiles, the search went from "guess the folder name" to "show me everything touched in this exact window" - which is a much more reliable way to search.
• Search by what a project contains, not what it's called. I didn't know the folder name. I did know it had to contain package.json and likely vite.config. Searching for the signature of the toolchain found it in seconds, in a location I never would have guessed to look - a separate sandboxed Windows user profile I didn't even know existed on my own machine.
• Different AI coding assistants can leave very different fingerprints on disk. Some generate plain project folders in your normal workspace. Others, like Codex's sandbox mode, isolate themselves into entirely separate environments - different user accounts, different node_modules, different everything. If you're switching between tools, it's worth knowing where each one actually puts its files.

The command, if you need it

If you're in the same situation - you know roughly when something was built but not where - here's the general-purpose version:

forfiles /P "C:\Users" /S /D +MM/DD/YYYY /C "cmd /c echo @path @fdate @ftime" 2>nul | findstr /I "package.json vite.config"

Swap package.json and vite.config for whatever filename fingerprint matches your stack - requirements.txt for Python, Cargo.toml for Rust, composer.json for PHP. The principle is the same: search for the file that's guaranteed to exist, not the folder name you might have forgotten.

Once you find a candidate, confirm it before getting too excited:

cd path\to\folder
type package.json

That one command tells you the project name, dependencies, and scripts - enough to know immediately whether you've found the right thing.

Small investigation, but a satisfying one. Sometimes debugging isn't about the code at all - it's about reconstructing your own past actions from whatever digital breadcrumbs you left behind.