0.9.1-rc.1 status — we are past the date we gave, and I owe you an explanation

We said "this weekend" on 16 July. It is now the 26th. That date is missed, and I would rather explain exactly why than quietly re-target it again.

I also want to apologise for something with wider reach than the release slipping: this has been blocking almost everything else. Pull requests are sitting unreviewed, issues are waiting on first responses, and contributors have been waiting on me while two release-critical items consumed effectively all available capacity. That is a real cost to people who took the time to contribute, and it is on us, not on them.

Two things caused it. Both had to be done right rather than quickly.

1. The daemon was a much larger architectural shift than a feature

The coordination daemon (#1139) merged on 23 July at +90,029 / −3,477 across 192 files. That is not a feature landing; it is a change to how the whole system runs.

It had to coordinate multiple MCP sessions and subagents without duplicating indexing work, while handling startup and shutdown, cancellation, crash recovery, local IPC identity, install/update activation, filesystem permissions and path behaviour — consistently across macOS, Linux and Windows. A coordination layer that looks stable on one platform and quietly breaks lifecycle or safety guarantees on another is worse than no coordination layer, so it absorbed far more verification effort than the implementation itself.

#1252 is the follow-up hardening pass on that work: +6,060 / −302 across 53 files, covering safe agent-config repair, deterministic parallel test scheduling, full release-fixture smoke coverage, and Windows-specific safety work. No new daemon features — just making the release paths trustworthy.

2. We found the root cause of #581, and it was severe

While hardening the release we finally reproduced and root-caused the Windows memory leak in #581 — the one where the process climbed past 50 GB of commit charge over hours and took the whole machine down with it. That report has been open since 23 June, and every earlier attempt only moved the symptom.

Yesterday it resolved into two independent Windows-only defects, both now fixed on the #1252 branch:

Thread-heaps were never released. A static MinGW link has no DllMain and registers no TLS callback, so nothing ran at thread exit and every thread abandoned its mimalloc thread-heap for the life of the process. After 300 MCP requests the allocator reported 607 thread-heaps — peak equal to total equal to current, none ever released — holding 170.5 MiB against a live set of roughly 300 KiB, growing linearly and without bound. POSIX was unaffected because a pthread TSD destructor already did this, which is precisely why every POSIX soak stayed flat under an identical workload. Worse, those heaps were invisible to mi_heap_visit, which only walks the main and calling heaps — so the growth appeared to belong to no allocator at all, and survived every allocator setting we tried against it.

One OS thread per daemon connection. Each connection minted a fresh thread-heap, and mimalloc took new slices at its arena commit frontier for each one without ever walking back to the purged slices behind it. Windows commit charge and RSS therefore ratcheted upward for the entire life of the daemon. POSIX hid this too, because madvise drops purged pages from RSS regardless of where the frontier sits. The worker slots were already pooled and bounded; only the threads were not. They are now pooled and parked on a condition variable, keeping the set of thread-heaps constant.

Finding this needed new instrumentation, because the growth did not route through the allocator at all and so was invisible to allocator-level tools. We added phase marks that attribute OS committed-byte deltas to a labelled code path. Pointed at #581 they localised it in two steps: dispatch_tool held +102 MB across 27 requests while scope begin/end and idle stayed flat — which independently killed the theory that the growth was time-based — and splitting the handler put +88.4 MB in store resolution against +14.1 MB for the query body, with the matching release returning only −35.9 MB. A net ratchet of roughly 2 MB per request that never comes back. That single number explains the original 50 GB report, why it scaled with corpus size, why every tool appeared to leak identically, and why only Windows ever showed it.

Why this stopped everything else, and not just the release

A leak that ends in the operating system killing a user's machine is the most severe class of bug this project can ship. It has been affecting Windows users since at least v0.8.1. Once it became reproducible we were not going to cut a release candidate around it, and we were not going to paper over it with a workaround when the actual cause was finally in reach.

But severity alone is not the whole reason work halted. The real reason is how much of the system these two changes touch at once, and how deep they sit.

Between them they cross the memory allocator and its thread-heap lifecycle, process and thread lifecycle in the daemon, the store-resolution path that every single tool call runs through, IPC identity and filesystem permissions, and the install/update/release surface on three operating systems. Those are not independent areas that can be reviewed in parallel — they are layers stacked on each other, and the leak fix in particular lives underneath everything: it changes when memory is released across the entire process.

That has an unavoidable consequence for other work. Merging unrelated changes into a tree whose allocator behaviour, thread lifecycle and store-resolution path are all actively moving means neither change can be trusted afterwards. If a PR merged today and a Windows soak drifted next week, we would have no way to tell whether the cause was the contribution or one of the layers underneath it. Reviewing against a moving foundation produces reviews that have to be redone.

So the honest position is not "we were busy." It is that the change surface is currently wide enough and low-level enough that holding other merges is the responsible choice rather than a scheduling failure. Both pieces had to be done properly rather than quickly, and together they consumed effectively all of the capacity available right now.

I would rather say that plainly than let contributors keep guessing why their PR has been silent.

Where things stand

• Token-consumption work: landed in main (Tree-format tool output: prefix-grouped rows, exactly-once pagination, real change impact, cycle detection #1154, prefix-grouped tree output) and testable now
• Daemon: merged (feat: coordinate concurrent CBM sessions #1139)
• Release hardening + the two Memory leak: process grows to 50+ GB virtual memory over hours/days, crashes Windows #581 fixes: in review on fix: harden daemon release paths and verification #1252
• 0.9.1-rc.1: follows once fix: harden daemon release paths and verification #1252 is green and the Windows soak confirms a flat baseline over hours rather than minutes

I am deliberately not naming a new date. The last one did not survive contact with #581, and another missed date is worth less to you than an honest status.

To contributors specifically

If your PR or issue has been sitting: thank you for your patience, and sorry for the silence. I have just been through the backlog and left a real, code-grounded response on every open item that had never had one — several turned out to be already fixed on main, and a few turned out to have a different root cause than reported. Reviews resume in earnest once the release path is clear.

And to @baoyu0, who reported #581 back in June and patiently ran retests for us: thank you. You were right that the short-run RSS test proved nothing, and you were right to push for a real soak. The cause turned out to be in a place none of our allocator tooling could see.

Quick status update on v0.9.1-rc.1 — and an apology

The RC is code-complete: the full cross-platform test matrix, the soak legs, and the smoke tests are all green on the release build. But we've hit a wall at the very last gate, and I want to be transparent about it.

Our release pipeline scans every artifact on VirusTotal before anything gets published. The Microsoft Defender engine there currently flags several of our Linux x86-64 binaries as Trojan:Script/Wacatac.B!ml — a machine-learning heuristic verdict (note: a Script-family detection on a native ELF executable), with the other 60+ engines reporting clean. Meanwhile an actual, up-to-date Microsoft Defender endpoint — signatures updated the same day, real-time protection on — scans the identical bytes and finds nothing.

We've spent several release cycles trying to eliminate this from the build side (full symbol stripping, removing the in-binary self-update/downloader entirely, moving Windows to a single binary) and each change helped only until the classifier flipped again on a later build. It's a decision-boundary artifact of the ML model, not something in the code.

For context, this is the same pattern opencode ran into across many of their releases: anomalyco/opencode#3415

We're treating this as a hard release blocker. I'm sorry about the additional delay on top of everything — the code is ready, but I'm not willing to publish a release that carries a "trojan" detection, even a demonstrably false one. What we're doing about it right now: false-positive reports to Microsoft for the exact affected hashes, a double-verification gate in the pipeline (VirusTotal cross-checked against a real Defender endpoint), and we've started setting up code signing for our release binaries — the durable fix opencode eventually landed on, though it's more a bureaucratic process than a technical one and will take a few weeks.

If anyone here has been through this — Defender ML false positives on large unsigned binaries, experience with Microsoft's false-positive submission turnaround, Azure Trusted Signing vs. alternatives — I'd genuinely appreciate your recommendations, right here in this thread.