0.9.1-rc.1 preview

[DeusData]

We are targeting the first 0.9.1 release candidate for this weekend.

0.9.1-rc.1 will focus on two of codebase-memory-mcp's central promises: reducing token consumption and providing stable, efficient code intelligence across demanding agent workflows.

This release candidate targets several of the largest remaining gaps:

Lower-token tool output

A recent output regression caused some tools to return far more internal graph data than agents actually need. The release candidate introduces compact TOON output across the main query surface, removes unnecessary internal artifacts from default responses, adds strict output budgets, and keeps verbose JSON available when explicitly requested.

The objective is straightforward: agents should receive the evidence they need without spending context tokens on repeated keys, internal similarity data, or oversized source payloads.

Stable multi-session operation

We are also working on a new local CBM daemon for environments running multiple coding-agent sessions and subagents at the same time.

Instead of allowing every session to independently start indexing, watching, and memory-intensive work, the daemon coordinates compatible sessions, coalesces duplicate operations, applies memory and admission limits, and cancels session-owned work when that session disconnects.

The goal is stable CPU and memory behavior even when several agents or subagents are exploring the same repository concurrently. The daemon remains entirely local. It does not introduce cloud processing, telemetry, or an external service.

Experimental agent tiers

For clients that support custom agents or subagents, we are introducing three experimental evidence tiers:

• Scout for narrow, provisional discovery using only a few focused calls
• Verify for normal task-directed investigation
• Auditor for bounded, paginated, and more exhaustive verification

These profiles are intended to let smaller or lower-cost agents handle focused discovery without paying the token cost of a full audit, while still escalating to stronger verification when correctness requires it.

The integration work now covers more than 40 automatic or conditional coding-agent and client surfaces, although the exact behavior depends on what each client supports.

Why this is a preview

This release candidate deliberately includes significant changes to output contracts, process coordination, and agent behavior. We therefore plan to publish it as a preview release rather than immediately declaring it stable.

We want power users to test it with real multi-session and subagent workloads before the final 0.9.1 release. In particular, we want feedback on:

• token consumption in real coding sessions
• behavior with multiple simultaneous agents and subagents
• daemon lifecycle, CPU use, and memory use
• whether Scout, Verify, and Auditor are useful boundaries
• which tasks can safely use smaller or lower-cost agent tiers
• any remaining oversized or low-value tool responses

Ideas, measurements, design proposals, and focused contributions are very welcome. If you have experience operating several coding agents against one repository, or have concepts for reducing context usage further without weakening correctness, we would especially like to hear from you.

The message for 0.9.1 is clear: lower token consumption, stronger performance, and stable operation across real multi-agent workflows.

[DeusData]

0.9.1-rc.1 progress update

A quick update on the release candidate: the token-consumption work has already landed independently in main.

The current implementation is the shared prefix-grouped tree data model introduced in #1154. It replaced both the earlier TOON output and the legacy object-per-node emitters. Structural results store the shared qualified-name prefix and file path once per group; rows beneath carry only the short symbol name and ordered data cells. The default text response renders that model as a compact tree, while format:"json" serializes the same columns, rows, and groups as structured JSON instead of returning a separate verbose shape.

This removes repeated keys, file paths, and qualified-name prefixes without losing exact join keys for follow-up calls. The same merge added byte ceilings, semantic floors, and context-explosion guards so output growth becomes a test failure rather than a future regression. Measured against the v0.9.0 release binary, a 192-hit search_graph response dropped from about 246 KB to 2.9 KB, the default architecture response from about 51 KB to 3 KB, and a seven-file detect_changes result from about 77 KB to 13 KB while becoming a real transitive blast-radius analysis.

Power users who are comfortable building a development snapshot can already test this tree-based output from main and share measurements, comprehension issues, or regressions with us.

The new coordination daemon in #1139 is still work in progress and is taking longer than we initially expected. It is also the part we consider most important to get right before publishing the release candidate.

This is a substantially larger package than a normal feature. The daemon has to coordinate multiple MCP sessions and subagents without duplicating indexing work or burning memory and CPU, while also handling startup and shutdown, cancellation, crash recovery, local IPC identity, installation and update activation, filesystem permissions, and path behavior consistently across macOS, Linux, and Windows.

We are working on it very actively, and the core design and much of the implementation are in place, but we do not want to rush a coordination layer that appears stable on one platform and introduces lifecycle or safety problems on another. The daemon remains entirely local and does not add cloud processing, telemetry, or an external coordination service.

So the current status is:

• the prefix-grouped tree output and token-consumption improvements are landed in main and can be tested now
• the daemon remains the release-critical work item
• the preview release will follow once the cross-platform daemon lifecycle and safety checks are genuinely ready

The platform-agnostic daemon is a large and critical change. We would rather take the additional time now than ship a coordination layer that is difficult to trust in long-running, multi-session workflows. Thanks for your patience while we finish it properly.

[hetasshi]

Come on, guys, I’m waiting!! I’m waiting for your update!

[DeusData]

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.

[DeusData]

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.

[DeusData]

v0.9.1-rc.1 is out. 🎉

➡️ Release notes and downloads

The antivirus false positive I described above is resolved: all 20 release artifacts scan clean on VirusTotal, 0 detections — every binary, both install scripts, and the notices files. The three Linux builds that were previously flagged with Trojan:Script/Wacatac.B!ml now come back clean, so the release passed our normal zero-detection gate on its own terms, with no exception made and nothing to explain away.

Being straight about the cause, since I was straight about the problem: I can't prove why it's clean now. The strongest single piece of evidence in the whole investigation was that one identical file (same SHA-256, not a rebuild) went from 0/62 clean to flagged within about an hour, which means part of that verdict lives in the scanner's own state rather than in our bytes. So some of this may be timing.

What I can say is that the artifact genuinely changed, and the changes are ones we should have made regardless:

• Every Linux binary we have ever shipped had an executable stack. One assembly file in the build was missing a .note.GNU-stack annotation, which makes the linker assume the worst for the entire link. Fixed and now asserted on the shipped artifact.
• A test-only probe that forks a SIGTERM-ignoring child was compiled into production builds. Gone.
• The daemon spawned curl against the GitHub releases API on the first eligible session of every run, just to report that a newer version existed. Removed — cbm now makes no network request of its own accord, and the archives contain no download URLs at all.
• An in-memory archive extractor with no production caller, and SQLite's loadable-extension machinery we never use, are both compiled out rather than merely unreachable.
• Temp-file and repository-scan hardening (private exclusive creation; symlinked directories can no longer lead a scan outside the project root).
• Build-time timestamps removed, so identical source can produce identical bytes.

All of it is now enforced by a release gate that checks the shipped binary for each property, so a future build can't quietly regress one. Full details are in the release notes under Antivirus false positives on release binaries, which also covers the code-signing work that remains the durable fix.

What would help most now: run the RC in your real workflows — especially multi-agent setups, long agent loops, parallel indexing, daemon start/stop cycles — and tell us anything that feels off. And if you can, ask your agent to run check_index_coverage across your repositories and paste the summary into an issue or discussion. Those aggregate numbers point us straight at concrete parser and resolver gaps, and they're the one thing we genuinely cannot generate ourselves.

Thank you for the patience on this one. The delay was real and the explanation above is the whole of it.

[rarepops]

The Windows UI RC script reinstalls 0.9.0 for me, unless I am doing something wrong. Anyway, the updating experience is pretty poor in general, there must be a nicer way to handle it?

[DeusData]

@rarepops Thank you for reporting this, and sorry the installer follow-up went unanswered. The thread does not identify the exact PowerShell invocation or script revision, so I cannot reliably explain why it selected 0.9.0. If the problem still occurs, please share the exact command, script URL or release tag, resulting version, and sanitized output. That would let us distinguish release selection from installation failure without guessing.