| v2026.10.19.0 | ### Added - **Codex CLI support.** `m3 setup` finds Codex, adds m3 to `~/.codex/config.toml` and wires two hooks into `~/.codex/hooks.json`: session start, and chat capture after every turn (`chatlog_ingest --format codex` reads Codex's session files). Upgrades and `m3 doctor --fix` repoint a stale entry. With the m3 Codex plugin installed, setup leaves these files alone. **Affected:** Codex users · **Action:** run `m3 setup`, then approve the hooks once in Codex with `/hooks` · **D | High | 10/19/2026 |
| v2026.10.17.3 | ### Changed - **Native core 3.10.172.** On Windows, importing the CUDA core and installing the embed service no longer flash a console window. The in-process embedder, the embed server and the FIPS settings take their values from `m3_config.toml` only: `M3_EMBED_*`, `M3_FIPS_MODE`, `M3_FIPS_STRICT` and `M3_HASH_PROVIDER` are not read, and `M3_MEMORY_ROOT/config` no longer locates the config. **Affected:** installs with the native core; an embed server configured by its service def | High | 10/18/2026 |
| v2026.10.17.1 | ### Changed - **`python-dotenv` 1.2.2 is accepted again** (the floor was 1.2.3), so m3 installs beside tools that pin 1.2.2. **Affected:** installs that share an environment with such a tool · **Action:** none · **Data status:** none. ### Fixed - **The FIPS "no wolfSSL" error names the folders it searched.** It used to say `~/.m3/lib` even when the config root had moved m3's lib folder elsewhere; it now lists each path tried and says to set `M3_LIB_DIR`. **Affected:** installs in | High | 10/17/2026 |
| v2026.10.7.1 | ### Fixed - **`m3 stop`, setup and upgrades no longer stop programs that merely mention an m3 process.** A terminal running `grep m3-embed-server`, a `tail -f` of an m3 log or an editor with an m3 script open could be stopped as if it were that process; only processes that run it are stopped now. **Affected:** all platforms · **Action:** none · **Data status:** none. - **An upgrade that updates the Claude Code plugin says so in one line and asks for one action: restart Claude Code.** | High | 10/8/2026 |
| v2026.10.7.0 | ### Fixed - **Linux: an upgrade that installs a new native core restarts the Rust embed server.** In 2026.10.6.0 the server kept the previous core and setup only printed the restart command. **Affected:** Linux installs with the Rust embed server · **Action:** none; `m3 upgrade` restarts a server still on the previous core · **Data status:** none. - **`m3 upgrade` finds its own launcher when the shell's PATH lacks the pipx bin directory,** instead of reporting m3 as not installed. | High | 10/7/2026 |
| v2026.10.5.0 | ### Fixed - **`m3 upgrade` on Windows no longer removes m3 when one of its programs is in use.** It now stops before changing anything, names what is holding the file, and prints the command that works; after any failed upgrade it reports what is actually installed. **Affected:** Windows pipx installs, in particular with Developer Mode on, or with an agent's m3 server running · **Action:** if the upgrade stops, run the command it prints · **Data status:** none. - **The hourly wareh | High | 10/6/2026 |
| v2026.10.4.3 | ### Fixed - **Fresh pipx installs get the native core and the shared embed server.** Installs made with recent pipx versions ran without either. **Affected:** installs created with pipx 1.17 or later, all platforms · **Action:** if `m3 doctor` reports oxidation not installed, run `m3 embedder install-gpu` and then `m3 embedder install` · **Data status:** none. - **`m3 upgrade` stops before changing anything when the source pipx installed m3 from no longer exists,** and prints the c | High | 10/5/2026 |
| v2026.10.1.1 | ### Fixed - **The bundled `m3-embed-server` binary is executable again.** Every wheel in m3-core-rs `3.9.20` stored it non-executable (mode `0600` on Linux and macOS, `0644` on Windows), so on a fresh install the shared embed server could not start — surfacing as an `EACCES` that named no cause. The Rust-core pin moves to **`3.10.1` / `v2026.10.1`**, whose wheels store it correctly and install executable under every pip tested (25.1.1 through 26.2.1) and uv. `m3 doctor --fix` contin | High | 10/2/2026 |
| v2026.10.1.0 | ### Fixed - **PostgreSQL could fail on m3's own text.** The connection pool adopted the server's `client_encoding` instead of pinning its own, so against a `SQL_ASCII` cluster every non-ASCII character m3 writes raised `UnicodeEncodeError` inside the driver — and m3's own schema and messages contain them, so the first schema load died pointing at the driver rather than at the encoding. The pool now requests UTF-8, which is correct against any server encoding; an explicit `client_enc | High | 10/1/2026 |
| v2026.9.21.0 | ### Fixed - **The cognitive loop stopped embedding chat turns until it was restarted** ([#180](https://github.com/skynetcmd/m3-memory/issues/180)). Each embed sweep set `M3_DATABASE` and left it set, so after the chatlog store was swept every later database resolution in the process pointed at it. The loop's own store list then collapsed to a single entry, the chatlog store dropped out of the embed targets, and `unembedded` grew without bound while the loop reported no work to do. T | High | 9/22/2026 |
| v2026.9.20.3 | ### Fixed - **`sync_all` reported "all systems synced" after replicating nothing.** When the sync could not take its lock it returned without error, so the process exited 0 and the runner — which judges on the exit code — called it a success. A skip now exits 75 (`EX_TEMPFAIL`) and is reported as `SKIPPED — nothing replicated`, so a scheduled or CI caller can tell a no-op from a completed sync without parsing the log. - **The skip message named a cause nobody checked.** It said "anoth | High | 9/21/2026 |
| v2026.9.20.0 | ### Added - **Memories now have dynamics rather than a fixed importance.** Decay runs toward a floor that varies by what a memory has earned instead of toward zero, frequently-retrieved memories fade more slowly, and pinned rows are unchanged. A memory retrieved hundreds of times previously decayed at exactly the same rate as one nobody had touched in a year. - **`memory_grade`** — after answering, an agent can report which retrieved memories it actually relied on. Helpful and unhelpf | High | 9/20/2026 |
| v2026.9.17.0 | ### Changed - **Startup registers 10 tool schemas instead of 20** — about 2% of a 200K context window, down from 3%. Every other tool is reached as before, through `tools_load_domain` or by name with `m3_call`; `M3_TOOLS_LAZY=0` still registers the full catalog. - `chatlog_status` and `files_health` moved into the `diagnostics` domain, so that domain now covers all three stores. - Corrected tool counts and context percentages across the documentation, and documented that an MCP discon | High | 9/18/2026 |
| v2026.9.14.4 | ### Fixed - `notifications_poll` no longer returns claimed rows. An in-flight message was offered to every poller, so two agents could do the same work. The unread path now selects PENDING through `message_state_sql`; the audit view (`unread_only=False`) still shows claimed work. - `notifications_ack` and `notifications_ack_all` no longer complete a row held under another agent's lease. Both skip claimed rows and report what they left behind; ack by id distinguishes a claimed row from | High | 9/15/2026 |
| v2026.9.14.1 | ### Added - **Narrowed tool variants**: `memory_search_slim`, `memory_write_slim`, `chatlog_search_slim`, `memory_supersede_slim`. Same implementations as the full tools, fewer parameters. Default startup set is ~2,216 tokens of schema against ~33,686 for the whole catalog. - **`as_records`** on twelve display-string tools: opt-in JSON records instead of the display string. Default output is unchanged. Errors return `{error, ...}` without `count`/`items`. - **User-owned startup tool s | High | 9/14/2026 |
| v2026.9.13.2 | Release 2026.9.13.2. See CHANGELOG.md. | High | 9/13/2026 |
| v2026.8.29.1 | > A one-line fix for a bug that hid behind its own default. Selecting a type in > the dashboard's KB Browser raised `no such column: mi.type`; leaving it on > "all types" worked perfectly — because "all types" emits no predicate at all, > so the broken SQL was never generated. ### Fixed — KB Browser type filter - **`Error scanning DB: no such column: mi.type`** when selecting any type in the dashboard's KB Browser (reported against 2026.8.19.16 on Ubuntu / Python 3.12). `dialect().scope_p | High | 8/30/2026 |
| v2026.8.19.16 | > A release about silence. Every fix here is a path that was already broken and > said nothing: a hook that died before it started, seven scheduled jobs firing > into a void, a repair reporting success over an empty database, and a doctor > confidently diagnosing the wrong machine. None of them raised an error; you > found out by noticing a timestamp had stopped moving. ### Fixed — capture and background jobs on Windows - **Chatlog capture was dead on Windows, silently.** Both config writers e | Medium | 8/12/2026 |
| v2026.8.7.0 | ### Fixed - **File fact-extraction now reaches the same LLM the rest of m3 uses.** It no longer reports "no LLM" when the optional `M3_FILES_*` override vars are unset: the extractor falls back to the shared `llm_failover` resolution (which auto-discovers a local LLM), and authenticates via the shared, headless-safe token resolver rather than reading the environment alone — so it works in headless launchers (launchd/systemd/task) that don't inherit the shell env. ### Added - **`m3_sdk | High | 8/8/2026 |
| v2026.7.26.0 | ### Fixed - `m3 chatlog doctor` no longer reports `<hook> silent 24h+` permanently; the check treated an absent per-hook timestamp as infinitely stale. - Chatlog unembedded count excluded soft-deleted and empty rows, so it disagreed with the tool that drains it and could never reach zero. - Cognitive loop's embed pass only swept the main DB; on a split topology the chatlog backlog grew unbounded. - `m3 doctor --fix` repaired only the main DB and reported success while the real backlog went untou | High | 7/26/2026 |
| v2026.7.14.0 | **m3 is now a drop-in memory backend for LangChain / LangGraph.** Install the optional extra and reach four standard surfaces from `m3_memory.langchain`: - **`Memory` / `MemoryClient`** — Mem0-compatible. Migrating from Mem0 is a one-line import swap (`from m3_memory.langchain import Memory`); `.add()` / `.search()` keep their signatures and return shape. m3 shadows Mem0's API but never imports it. - **`M3Store`** — a LangGraph `BaseStore`, so `create_react_agent(store=M3Store())` gives any age | High | 7/14/2026 |
| v2026.7.1.2 | **Full Changelog**: https://github.com/skynetcmd/m3-memory/compare/v2026.7.1.1...v2026.7.1.2 | High | 7/2/2026 |
| v2026.6.21.0 | ## Highlights ### LongMemEval-S v3 benchmark report — 92.0% QA, no oracle metadata The published LME-S benchmark is now the **v3 no-oracle** result: **92.0% end-to-end QA accuracy (460/500)** with all routing inferred from the question text at runtime — no dataset `question_type` labels at answer time. Answerer: Claude Opus 4.6; judge: unmodified upstream gpt-4o. This supersedes the prior oracle-routed **89.0%** headline. Retrieval session-hit-rate is unchanged at **100% @ k=20** (99.2% @ k=10) | High | 6/22/2026 |
| v2026.6.8.2 | Documentation-only release; no code or behavior changes. Installs/runs identically to 2026.6.8.1. ## Documentation - **Comparison accuracy & sourcing** — competitor benchmark figures in the Sovereign Substrates table verified against primary sources and corrected/cited; metric mismatches (recall vs. QA accuracy) and a disputed entry are clearly caveated. - **Retrieval vs. QA metric framing** — README, comparison table, core-features, and myths pages now distinguish retrieval session-hit-rate (t | High | 6/9/2026 |
| v2026.6.8.1 | ## Added **LongMemEval-S session-hit-rate results from [xiaowu0162/LongMemEval#43](https://github.com/xiaowu0162/LongMemEval/issues/43).** The engine-upgrade SHR table is now in the README: | k | SHR | Hits / 500 | vs. prior report | |---:|---:|---:|---:| | 5 | **98.2%** | 491 / 500 | +2.0pp (was 96.2%) | | 10 | **99.2%** | 496 / 500 | +2.4pp (was 96.8%) | | 20 | **100.0%** | 500 / 500 | first time reported | **k=10 is M3's default search depth** — every column above uses the same engine set | High | 6/8/2026 |
| v2026.6.1.0 | Faster, more resilient, more efficient and more robust while maintaining backward compatibility. FIPS 140-3 ready. Local first, cloud capable memory engine. | High | 6/1/2026 |
| v2026.5.30.0 | ## Entity coalescing v2 (reversible apply/unapply) + catalog registration + CLI exit-code fix ### Added - **Entity-coalescing v2 — reversible overlay apply/unapply** (`files_entity_coalesce_apply` / `files_entity_coalesce_unapply` MCP tools; `entity-coalesce-apply` / `entity-coalesce-unapply` CLI). Materializes reviewed/auto-merge candidates as a reversible `same_as` + shared-`cluster_id` overlay — members are never deleted, the canonical view is a read-time projection, a deterministic represe | High | 5/30/2026 |
| v2026.5.21.0 | ## v2026.5.21.0 — green-CI maintenance release First release on fully-green CI (Lint, Type Check, Security, and Tests on ubuntu/macos/windows all passing). ### Fixes - **F821 undefined-name errors (30)** — the Phase 7+8 modularization left dangling symbol references in `memory/write.py`, `search.py`, `enrich.py`; restored the missing imports and re-exports. - **Mypy type errors (64)** — resolved across `bin/`: missing `memory_core` re-exports, `m3_core_rs` typing, exception-base annotations, h | High | 5/21/2026 |
| v2026.5.18.1 | **Full Changelog**: https://github.com/skynetcmd/m3-memory/compare/v2026.5.18.0...v2026.5.18.1 | High | 5/18/2026 |
| v2026.5.6.3 | ## Highlights - **GitHub Actions Node-24 upgrade.** Pins every workflow action to its latest Node-24-compatible release-tag SHA so CI keeps working past GitHub's Node 20 removal on 2026-09-16. | action | from | to | | --- | --- | --- | | `actions/checkout` | v4 | **v6.0.2** | | `actions/setup-python` | v5 | **v6.2.0** | | `actions/upload-artifact` | v4 | **v7.0.1** | | `actions/download-artifact` | v4 | **v8.0.1** | - **New banner art** at `docs/M3-banner.jpg`. ## Migration notes Major-vers | High | 5/7/2026 |
| v2026.5.1.1 | ## Highlights This release rolls up roughly five weeks of ingest-pipeline work plus a documentation, hygiene, and security pass. - **Tool count: 66 → 72.** Six new MCP tools: `entity_search`, `entity_get`, `extract_pending`, `enrich_pending`, `memory_search_routed`, `memory_write_from_file`. See [`docs/MCP_TOOLS.md`](https://github.com/skynetcmd/m3-memory/blob/main/docs/MCP_TOOLS.md). - **`bin/m3_enrich.py` CLI** — first-class user-facing enrichment over the Observer/Reflector pipeline. Durabl | High | 5/1/2026 |
| v2026.4.24.12 | ## Two pain points caught testing the plugin on Windows ### Plugin commands now self-resolve Caught when `/m3:doctor` ran on Windows: `pip install --user m3-memory` puts `mcp-memory.exe` at `%APPDATA%\Python\Python<NN>\Scripts`, which is **not** on Windows PATH by default. The plugin command had Claude spelunking through 8 fallback paths before finding `python -m m3_memory.cli` works. `/m3:doctor`, `/m3:status`, and `/m3:install` now explicitly list the resolver chain in their command bodies: | High | 4/25/2026 |
| v2026.4.20 | ## Fixes - Resolve SQLite deadlock in `memory_consolidate` via connection reuse in `memory_link_impl` - Resolve database contention and sync hangs on large DBs (migration timeout bump, SAVEPOINT-wrapped pg_sync, VACUUM skip for >500MB DBs, WAL contention fix in `record_history`) ## Features - `memory_search` gains `recency_bias` (float) and `adaptive_k` (bool) params - `conversation_search` auto-pairs user turns with adjacent assistant replies (0.85x score) - `precedes` / `follows` added to `VA | High | 4/17/2026 |
| v2026.4.19 | Fix PyPI rendering: absolute URLs for all links and images, markdown banner fallback, incorporate doc edits. | High | 4/16/2026 |
| v2026.4.18 | Fix PyPI page rendering: banner image, absolute links, demo SVGs. | High | 4/16/2026 |
| v2026.4.17 | Docs-only release: Unicode emoji rendering fix for PyPI page. All markdown files now use Unicode emoji characters instead of GitHub `:shortcode:` syntax, which PyPI's renderer doesn't support. | High | 4/16/2026 |
| v2026.4.16 | ## What's new since v2026.4.8 - **46 MCP tools** (was 25) — added agent registry, handoffs, task trees, notifications, scoped memory - **89% on LongMemEval-S** (445/500) — full writeup with methodology and caveats in `benchmarks/longmemeval/README.md` - **Multi-agent orchestration** — coordinate multiple agents on shared local memory with built-in handoffs, inbox, and task assignment - **Conversation grouping** — `conversation_id` on write/search/update for session-aware retrieval - **Refresh l | High | 4/16/2026 |
| v2026.4.6 | ## What's New M3 Memory is a local-first agentic memory layer for MCP agents — 25 tools, hybrid search (FTS5 + vector + MMR), contradiction detection, cross-device sync, GDPR-ready, 100% local. ## Install ```bash pip install m3-memory ``` Or clone for development: ```bash git clone https://github.com/skynetcmd/m3-memory.git cd m3-memory pip install -r requirements.txt ``` ## Highlights - **25 MCP tools** — write, search, link, graph, verify, sync, export, and more - **Hybrid search** — FT | High | 4/10/2026 |
| v1.0.03 |  Intelligent Agentic Memory Most agent memory systems solve one problem well — vector search, or persistence, or multi-tenancy. M3 Memory solves all of them in a single, tested, local-first package that runs on your hardware without sending a byte to the cloud. *Here's how it actually gets used.* You're working on your MacBook at a coffee shop, asking Claude to debug a deployment issue. It remembers | Medium | 4/7/2026 |