Some bugs only appear when you have a long path, a Windows machine, and a vector database that spawns a subprocess. This is the story of the one that taught me why cross platform really matters.
I am Aniruddha Adak, GitHub ** @aniruddhaadak80**, a full stack and AI engineer from Kolkata. I love working on
Python
, Next.js
, TypeScript
and agent frameworks.My open source journey started with a simple card addition in 2024 and grew to 29 plus merged PRs across projects like topoteretes/cognee
, openclaw/openclaw
, NousResearch/hermes-agent
, google-gemini/gemini-cli
.
This post is my entry for Smash Stories for DEV Summer Bug Smash 2026. It is the chaotic story behind one of my favorite bug fixes, and how Google Antigravity helped me smash it.
Picture this. You are building a RAG pipeline with Cognee. On Mac and Linux, everything works fine. You push your code, a contributor on Windows tries it, and suddenly you get OSError: [WinError 3] The system cannot find the path specified
.
It happens inside LanceDB, when Cognee tries to persist vector data to the local filesystem.
The issue was #2941 in cognee. It was not a random error. It was a systematic Windows limitation colliding with how LanceDB spawns subprocesses.
On Windows, there is a legacy MAX_PATH limit of 260 characters. When paths get long, you need to prefix them with \\?\
to tell Windows to allow long paths. Most Python code forgets this, because on Unix you never need it.
Cognee was building absolute paths like C:\Users\aniruddha\projects\cognee\.data\vector_db\...
and passing them to LanceDB, which then created even deeper nested files. On long project paths, the final path crossed 260 characters and Windows refused to create it, but only when LanceDB tried to access it from a subprocess.
This is the kind of bug that never shows up in CI if your CI only runs on Ubuntu.
This bug was hard to catch for many reasons. It was OS specific and only appeared on Windows with long project paths. It was indirect because the error came from LanceDB, not from Cognee code directly. It was path dependent because short paths worked and long paths failed. It was subprocess related because the main process could sometimes create the folder, but the child process could not see it without the long path prefix.
I saw many users reporting similar issues but blaming LanceDB. The real fix needed to be in Cognee, where the vector_db_url
is normalized.
This is where my workflow changed. I used Antigravity agentic IDE with Gemini 2.5 Pro for the entire investigation.
For step one, understanding the codebase, I asked Antigravity where vector_db_url
is constructed and how it is passed to LanceDB. It traced the flow from config to LanceDB
adapter in seconds.
For step two, reproducing mentally, I asked Gemini to explain Windows long path prefix rules and when \\?\
is needed for absolute paths. It explained the \\?\
and \\?\UNC\
rules and that you must normalize with os.path.abspath
first.
For step three, writing the fix, I prompted Antigravity to create a helper that safely prefixes Windows absolute paths with \\?\
if not already prefixed, and leaves relative and Unix paths untouched. Antigravity suggested using os.name == 'nt'
check and handling both drive letter paths and UNC paths.
For step four, testing on Windows, I wrote the logic to be testable on any OS and then validated it later on a Windows VM via Crabbox. This is the same approach I used for openclaw
PR 90275.
For step five, edge cases, I asked Gemini to list edge cases. It gave me a clear list. Already prefixed paths should not be double prefixed. Relative paths should be left alone. Unix paths should be left alone. UNC paths need \\?\UNC\
handling. None
or empty strings should be handled safely.
This collaboration made the fix robust and it is why I am submitting for Best Use of Google AI.
My merged PR is fix(lancedb): automatically prefix windows paths to resolve OS Error 3 for long paths in cognee. The PR link is https://github.com/topoteretes/cognee/pull/3123 and it is merged and released.
import os
def normalize_vector_db_url(url: str) -> str:
if os.name != 'nt':
return url
if url.startswith('\\\\?\\'):
return url
abs_path = os.path.abspath(url)
if abs_path.startswith('\\\\'):
return '\\\\?\\UNC\\' + abs_path.lstrip('\\')
return '\\\\?\\' + abs_path
Then this normalized path is used when constructing the LanceDB connection. The subprocess now receives a path that Windows understands as long path enabled.
In simple terms, we tell Windows explicitly, this path is allowed to be long, please do not block it.
Before this fix, on Windows with deep project structure, lancedb
subprocess fails with OS Error 3
. After this fix, same structure works, because the path is prefixed automatically. No user action is needed. That is the best kind of fix, invisible to the user.
This was not my only Windows related battle. Here are all my merged bug related PRs that taught me cross platform thinking. All are merged only and no drafts are included.
| Project | PR Title | What it fixed | PR Link |
|---|---|---|---|
| topoteretes/cognee | fix(lancedb): automatically prefix windows paths | OS Error 3 on Windows long paths | |
Each of these is merged, no drafts, no closed without merge.
Cross platform bugs are real bugs. If your library claims to work on Windows, test the file paths on Windows. Subprocesses have different path rules. What works in your Python process may fail in a child process. Long paths are still a thing in 2026. Many tools still hit MAX_PATH. AI does not replace debugging, it accelerates it. Gemini helped me map the code and list edge cases, but I still had to understand Windows internals. Small fix, large impact. This 20 line helper unblocked every Windows user with a nested project.
I want to be clear about my setup because the challenge asks for Best Use of Google AI. I use Antigravity as my daily IDE for open source contributions. I use Gemini 2.5 Pro inside it for codebase search and call graph analysis, for writing reproduction scripts, for generating test cases for edge cases, and for drafting PR descriptions that maintainers love.
For this cognee bug, Antigravity reduced my exploration time from hours to minutes. I could focus on the actual Windows logic instead of hunting files.
I build with AI, but I ship with responsibility. Every line is reviewed by me before it is merged.
This bug taught me that the most legendary bugs are not loud. They are quiet, they only appear on one OS, on one condition, and they make a user think they did something wrong.
My job as a contributor is to make sure they do not have to think that.
If you are reading this and you work on a library that touches the filesystem, please test on Windows with a long path. You will be surprised what you find.
Links and credits
GitHub is https://github.com/aniruddhaadak80
Merged fix is https://github.com/topoteretes/cognee/pull/3123
Issue fixed is https://github.com/topoteretes/cognee/issues/2941
Challenge page is https://dev.to/bugsmash