A day after my AI fixed its own update bug (My first AGI moment), it found another bug — this time in a core third-party software stack it runs on. A real bug in the underlying open-source tool, not a configuration mistake. It diagnosed it, fixed it on my machine, and proved the fix against my real data. And the software still isn’t patched. Upstream, the bug is still there, waiting for someone else to find it.

Here’s the story, because the interesting part isn’t the fix. It’s the bug.

The silent failure

I was importing months of my AI chat history into my local knowledge graph when the import quietly failed. Not loudly — no crash, no error page. Eighteen files just silently refused to import, and the logs said something cryptic: SYMLINK_NOT_ALLOWED.

The files weren’t symlinks. There were no symlinks anywhere near them. The error was a lie, and finding out why it was a lie turned into a lesson about how open-source software gets tested — and why your own environment matters more than a green CI pipeline.

The bug: a Windows path separator

The knowledge graph tool — gbrain — checks every file path before importing to make sure it stays inside the repo. The check is a simple prefix test: the file’s real path must start with the repo’s root path. Path A starts with Path B, therefore safe. Straightforward.

The problem: on Windows, the function that resolves the real path returns backslashes. C:\Users\vaugh\brain\chatgpt\file.md. But the safety check was only comparing against forward slashes: C:/Users/vaugh/brain/. Every single Windows path failed the prefix test, got flagged as “outside the repo,” and was refused as a potential symlink attack.

The check wasn’t wrong. It was just written by people on Linux and macOS, where real paths use forward slashes and the test never fails. On those platforms the code worked perfectly, every day, in CI, in production, for thousands of users. On my Windows box it broke on every file. And nobody upstream knew, because nobody upstream runs Windows.

The fix

Four lines, one added boolean branch:

const safe = real === rootReal ||
  real.startsWith(rootReal + '/') ||
  real.startsWith(rootReal + '\\');   // ← Windows realpath uses backslashes

That’s the whole patch. Path is safe if it starts with the root plus a forward slash or a backslash. The fix is objectively correct — I verified it with instrumentation showing Windows realpathSync really does return backslashes — and it unblocked all 18 files on the live sync: 2,454 pages imported, fully embedded, queries hitting the new content.

Why CI could never have caught this

The repo has a full test gate for contributors: Docker spinning up four Postgres containers, a secret scanner, a parallel unit and end-to-end suite. I deliberately didn’t run it. Not because I was lazy — because it was the wrong test for this bug.

Think about it. The bug exists because the test suite runs on Linux and macOS, where real paths have forward slashes. A green CI run — even a perfect one, with every test passing — would never have caught this. The bug was invisible to the very pipeline that’s supposed to prevent bugs.

What caught it instead was the live production sync on my actual Windows filesystem, exercising the complete path — path construction, realpath resolution, safety check, import, chunking, database — against real data. For this specific change, the live test was stronger evidence than any unit test would have been.

So the honest calculus was: an hour of environment setup to run a suite that couldn’t have caught this bug in the first place, versus a live test that already proved the fix works. I chose the live test, and it passed.

The uncomfortable part

The patch works on my machine. It is not upstream. My local copy of the tool sits bun-linked to a clone of the source repo, so my edit fixes my install — but the next upgrade will overwrite it, and every other Windows user of this tool has the same bug, silently failing their imports with the same lying error.

The real cure isn’t the patch. It’s getting the fix merged into the project itself — and ideally adding Windows coverage to their CI, so the next path-separator assumption dies in the test environment instead of in a user’s log file.

The lesson

Open-source software is tested by people, on their machines, in their environments. A green CI pipeline proves the code works on the maintainers’ platforms — and if you’re running it somewhere else, you’re the test. Sometimes that means you find the bug, write the four-line fix, and file the issue upstream so the next person doesn’t have to.

That’s the deal with self-hosted software. The fix is often one line. The understanding takes the afternoon. And the patch — if you want it to matter to anyone besides you — takes an upstream maintainer saying yes.