Porting ripwire to Windows

The gap

ripwire is the ripgrep of AI context: a zero-dependency C++23 CLI and MCP server that gives coding agents a ranked map of a repository before they read it. It ran on Linux and macOS. Windows users ran the Linux binary inside WSL2 and wrote shims so their tools could find it.

On September 7 I opened #44: native Windows x64 on clang-cl and the MSVC ABI, with no external dependencies. It came to 8,891 added lines across 175 files, covering UTF-8 and long paths, symlinks and junctions, process trees inside Job Objects, file locking, the MCP directory watcher, PATH and PATHEXT search, and an ACL-protected cache directory.

How it was built

AI agents wrote the code. My job was everything around it: deciding what “works on Windows” had to mean, writing the gates that proved each piece, and reading every result before it went into the pull request. The first automated review pass posted twelve actionable findings. They were fixed the same day, the next two passes found one each, and the last found none.

The question that wasn’t code

The maintainer’s first answer was honest: a new platform is a support commitment that every future pull request inherits, and that was a scope decision to settle before any review. No timeline, no promise.

So I kept the branch alive. Main moved fast, and I merged it back four times in five days so the port never went stale while the decision was pending.

Numbers, not adjectives

On September 16 the maintainers decided to move all operating-system switching behind one header, src/infra/os.h, and to do that refactor themselves. They asked me to stop pushing. I held the branch and posted a local evidence snapshot instead: the Windows gates that passed, the builds that passed, what was still unproven, and a benchmark on the same NTFS volume.

The same report said what the numbers did not show: Linux on WSL’s own ext4 filesystem was still faster, so this was not a claim that Windows beats Linux. It also cut the worker peak from 28–29 threads to 20 on 16 logical CPUs.

“Jeepers! that is quite a measurement” ripwire maintainer, on the benchmark

The maintainers asked me to push the snapshot to its own branch so their refactor could build on it with my authorship intact. Eight fixes from the port changed Linux and macOS behaviour too, so they landed separately in #292, each credited to me and each with a gate that fails before the fix: unescaped JSON paths in wrap, a one-byte over-read in --expand, a race in the MCP edit lock, a read error reported as success, and memory released earlier during ingest, which lowered peak RSS on an LLVM subset by about 200 MiB.

Failing loudly

On September 19 the refactored branch was ready, but nobody had built it on Windows. It had only compiled against a hand-written mock SDK. I ran the maintainers’ checklist on real hardware and reported what happened: five build failures on the unmodified branch, the first error text for each, and every downstream item marked blocked instead of guessed.

Those five failures became concrete fixes. Two days later both clang-cl and Microsoft’s cl.exe built ripwire, a Windows CI job gated every full run, and native Windows shipped in 0.6.2.

“this was a contributor report that changed a release” ripwire maintainer, merging #44

After the merge

The 0.6.2 changelog credits the port to me by name. 0.6.3 added a Windows x64 release asset as a preview, and I tested it on a second machine and shell configuration in #334. Fixes from that round, including a PowerShell PATH hint, are credited in 0.6.4 and 0.6.5.

1. Sep 7#44 opened: native Windows x64, 175 files.
2. Sep 8Maintainers raise the scope question. No timeline.
3. Sep 16Branch held; evidence snapshot and benchmark posted.
4. Sep 19The os.h seam and eight credited fixes land. Windows run finds five build failures.
5. Sep 21#44 merged. Native Windows ships in 0.6.2.
6. Sep 250.6.3 ships a Windows release asset; second-machine test in #334.

What I’d tell anyone doing this with AI

• The agents write the code. You own the definition of done and the proof that you met it.
• Say what is not proven. The line about ext4 being faster did more for trust than any adjective.
• A precise failure report is a contribution. Five build failures with their first line of output moved a release more than a green claim would have.
• Follow the maintainers’ plan. Hold the branch, snapshot the work, never force-push over their refactor.

Want this kind of work on your codebase? Email me, or go back to lennix1337.github.io.