Contextify indexes your local Claude Code and Codex sessions into a local SQLite/FTS index so you can search and read your AI-coding history. It works purely locally, with an option for hosted or self-hosted cloud sync to read it on another machine.
Some of the folks asked for a Windows client, because their self-hosted setups include Mac, Linux, and Windows boxes all generating CLI AI transcripts, sometimes headlessly. Contextify started as a macOS app; 1.8.0 brings it to Windows (x64 and ARM64) and extends the Linux CLI. On Windows it is a background agent plus a CLI, with no history-browsing UI yet.
Pulling this off took a lot of interesting work, including a shared Swift core, in a way where it could still be updated as easily as before the release. Here are the harder bits.
The shared Swift core
The parser, schema and migrations, SQLite + GRDB + FTS5, query/export, and cloud sync are a single Swift codebase shared by the macOS app, the Linux CLI, and the Windows client. On Windows that core runs as a resident engine (contextify-windows-engine.exe) and the .NET/Avalonia tray just talks to it over newline-delimited JSON on stdio.
That is not how I built it originally. The first Windows client actually began as a full C# reimplementation with its own parser, SQLite, and sync. This was a mistake. I realized I was going to have a lot of drift, and since I already had shared Swift between Linux and macOS, it would be much better to bring Windows into that too.
I did a spike to prove Swift 6.3.3 + GRDB + a vendored SQLite could do an FTS5 write/search round trip on Windows 11 ARM64, and basically started over. It was a valuable change and put me on course toward a proper shared core. (More on ARM64 vs x64 later.)
Finding gaps along the way
One thing that extended the dev time: focusing on the Windows build and validating it revealed gaps in behavior between the macOS and Linux apps that I had missed. They had not been reported by users yet, but I saw the agent hitting unexpected errors running the Contextify CLI on Linux and was like, huhhhh?
So at one point I was adding things to the Swift core and backporting them to the Linux app, and dusting off tickets I had created specifically for these gaps but lost in the backlog.
Building Windows x64 from a Mac (with no x64 machine)
At the start of this, I did not realize that having an x64 Windows execution environment is not at all similar to the magic Rosetta unlocks in loading x64 applications on macOS. I learned that compiling x64 on Apple Silicon under emulation just is not practical; the build times are far too slow to iterate on.
I priced out real build boxes, but I could not convince myself to buy something when builds and QA would be so bursty. So I built the devops tooling to allocate and deallocate Azure virtual machine instances for QA and build instead.
Before turning to Azure, I used what was at hand: GitHub-hosted runners. But the cold starts and price/performance were no good; it was taking upwards of 40 minutes to spin up and tear down. The Azure x64 boxes I use deallocate at rest, so they only bill while actually compiling. A full cold cycle including spin-up and teardown is about 13 minutes.
Getting off GitHub's runners
GitHub also had two bad outages during this stretch, which added more yardage to the Windows release run. I refactored my CI completely away from hosted runners. Everything that is not x64 now builds and signs on hardware I own, a base-model Mac mini M4 (soon to be upgraded to an M5 Pro) and my MacBook Air M5. The only exception is x64, which uses the deallocate-at-rest Azure boxes described above.
Signing Windows releases
An unsigned Windows app hits users with warnings telling them not to run it. Contextify must at least be trusted by Windows 11.
Microsoft's recommended low-cost Azure signing service was a waste of time. It gates you behind a third-party identity check that would not accept my identity, failing repeatedly with no reason and no error code. Microsoft's docs are driven by some AI thing that does not work. The only free way to reach Microsoft is their support forums, where I still have no reply. People who paid for support have posted similar issues with no response.
The next best option seemed to be an SSL.com certificate signed through their cloud. I hemmed and hawed about getting my own YubiKey but finally just paid for their cloud key as well. Once I just sort of gave in and paid the money it was ~trivial to get my identity approved.
SSL.com's website is absurdly bad. Besides the design and navigation, they have UI that presents incomplete information that the support bot clearly has a pre-filled workaround for. Rather than just fix their website they put the workaround in their support chat. SSL.com has reached new heights in product maintenance and support cost control.
The joke is that the very first thing you see once you have authenticated is how to sign up to create affiliate links and resell their products.
Microsoft should either be on top of their own signing lane or enforce better experiences from their partners.
An interesting Swift bug
Swift on Windows is a real thing (!), but the concurrency runtime is younger there than on the Mac.
The resident engine crashed on Windows x64 with an access violation (0xC0000005) inside swift_task_localValuePush, before it parsed a single argument. Identical task-local code was fine on macOS and just hard-crashed on Windows x64: no error, straight to an access violation. In my case, the cause was carrying engine state through nested @TaskLocal values. I fixed it by passing an explicit Sendable context down the call chain.
Anyhow, I learned it is not all that unusual to hit async-Swift access violations on Windows that never show up on Darwin.
The app itself
Install is a per-user, unelevated setup: no admin, no Windows service, no MSI, and it self-updates. I have submitted a PR to add winget; for now it is the signed installer from the site or GitHub.
It is local-first: the engine is the only thing that writes the database, and cloud sync is opt-in behind sign-in. I would most like feedback on if and when indexing or sync breaks on real Windows setups, and any feedback on the overall UX of the app.