v2.11.0

Added

• ltm memory CLI subcommands — bunx @rohirik/openltm-core memory learn|recall|forget|relate|context gives headless/CLI agents (OpenCode CLI, scripts, cron, CI) a direct shell path to LTM without the agent TUI, slash commands, or a running MCP server. --json for machine-readable output; DB resolves via LTM_DB_PATH; writes route through the same scrubSecrets path as the MCP server. Exit codes: 0 ok, 1 usage, 2 runtime.
• Runnable mcp-serve — the full MCP server (tools, resources, prompts) moved into @rohirik/openltm-core/mcp (buildMcpServer/startMcpServer factory with injectable host-config hooks), so bunx @rohirik/openltm-core mcp-serve now starts the real stdio server on any machine instead of printing a "not yet implemented" stub. The Claude Code plugin's src/mcp-server.ts is now a thin wrapper — manifest path unchanged.

Fixed

• Unknown CLI sub-commands no longer launch the install wizard — ltm <typo> ... previously fell through to the installer; it now prints help and exits 1.

Docs

• README "CLI access for headless agents" section; troubleshooting guide for writing memories from a plain shell (slash commands are TUI-only) with an OpenCode plugin-load checklist.

v2.10.0

Added

• Code-anchored memory invalidation — memories can be anchored to the files they reference (learn's optional files param → new memory_files table, migration 023). The git post-commit hook flags anchored memories stale when a commit touches those files (config gitInvalidateEnabled, default true; importance: 5 exempt). This catches the high-traffic-but-stale memory that recency-decay and forget can't see — invalidation driven by code change, not recall behaviour.
• Stale-aware recall + decay — recall returns a stale flag and downranks stale memories (still returned); decayMemories deprecates flagged memories regardless of recall frequency. Nothing is deleted on invalidation — the flag is auditable.
• revalidate MCP tool — clear a stale flag after review when the code changed but the memory is still correct. Re-confirming a memory via learn also clears it; forget remains for truly-wrong memories.

Fixed

• bunx @rohirik/openltm-core "Script not found" — the package's only bin was named ltm, but bunx resolves a bin by the package basename. Added openltm-core and openltm bin aliases (keeping ltm), fixing the documented OpenCode install path.

v2.9.1

Fixed

• Honker handle now actually opens — v2.9.0 reported caps.honker = true but getHonker() silently returned null, leaving the queue/cron/pub-sub features dormant. Root cause: both the plugin and honker-bun's open() called the once-per-process Database.setCustomSQLite(), so honker-bun threw "SQLite already loaded". The plugin now neutralises further calls after loading the custom SQLite, so honker-bun reuses the already-active extension-enabled SQLite. Verified end-to-end (enqueue → claim → ack, pub-sub notify, scheduler register).

v2.9.0

feat(extensions): activate honker via vendored binary + discovery

Build libhonker_ext from source and vendor the darwin-arm64 binary so the
dormant Phase 8 honker paths (embedding queue, leader cron, pub/sub) go live
instead of no-op'ing to the pre-honker fallbacks.

- add locateHonkerExt() + honkerExtCandidates() discovery, mirroring the
  existing locateSystemSqlite()/systemSqliteCandidates() pattern
- flip wantHonker default false -> auto-on when a binary is discoverable;
  LTM_DISABLE_HONKER still force-disables, LTM_HONKER_EXT overrides path
- lib/honker.ts openHonker() uses discovery instead of env-only read
- extract firstExisting() helper, dedup the locate loops
- update extensions tests to the new contract (off via LTM_DISABLE_HONKER,
  on when vendored binary present)
- raise test --timeout to 15000 to kill the gdrive-FS load flake
- bump 2.8.1 -> 2.9.0 across all version refs

v2.8.1

Fixed

• OpenCode installer now ships its customization — the agents/skills/plugins are bundled in packages/openltm-core/assets/opencode/ so they actually deploy on published/bunx installs (previously read from the gitignored repo .opencode/, a silent no-op). Components co-locate with the resolved config dir.
• openltm-core npm bin — dropped the leading ./ so npm 11 stops stripping it; bunx @rohirik/openltm-core is executable again.

Changed

• npm publishing moved to OIDC trusted publishing — the Publish workflow authenticates to npm via GitHub OIDC instead of a long-lived NPM_TOKEN, and restores build provenance. No publish secret is stored.

v2.8.0 — OpenLTM: open source + rename

📣 OpenLTM is now open source

The plugin formerly known as ltm@ltm is now openltm@OpenLtm, MIT-licensed and open to fork.

Breaking

• Plugin renamed ltm → openltm; marketplace ltm → OpenLtm
• MCP tool prefix mcp__plugin_ltm_memory__* → mcp__plugin_openltm_memory__*
• Slash commands /ltm:* → /openltm:*
• npm @rohirik/ltm-core → @rohirik/openltm-core
• Repo claude-ltm-plugin → OpenLtm (old URL redirects)

Migration

Existing memory databases carry over automatically. Reinstall: claude plugin marketplace add https://github.com/RohiRIK/OpenLtm then claude plugin install openltm.

Note: releases v2.2.0–2.7.x were shipped via marketplace (plugin.json version) without GitHub release tags; this release resumes tagging.

v2.1.1

fix(hooks): bundle GitCommit hook with esbuild — no workspace dep on fresh installs

• Pre-bundle GitCommit hook (52 KB, zero workspace deps at runtime)
• CI bot auto-rebuilds bundle on source change
• Fix ltm-core TLA patterns for esbuild compatibility

v2.1.0 — Pi MCP bridge, sync tool registration, provider exports

Changes

Pi adapter: complete rewrite — MCP bridge with sync tool registration

The root cause of the Pi LTM tools not appearing was a two-part problem:

1. Wrong install target: The published 2.0.2 was missing the "pi": { "extensions": [...] } key in package.json — Pi couldn't discover the extension entry point.
2. Race condition: Tools were registered asynchronously (after MCP handshake), but Pi collects its tool list synchronously right after calling the extension factory. Tools registered asynchronously were invisible to Pi.

Fix: Pre-register all tools synchronously at extension load time with their known schemas. The execute() function awaits the MCP bridge being ready. Pi sees 7 LTM tools immediately.

Also switches from direct @rohirik/ltm-core imports (requires bun:sqlite, unavailable in Pi's Node.js runtime) to an MCP stdio bridge: spawns the ltm-core MCP server as a Bun child process and proxies tool calls via newline-delimited JSON-RPC.

Other fixes

• ltm-core: export provider factories and setting constants from package root
• graph-server: import shared-db helpers from @rohirik/ltm-core
• bunfig.toml: set test timeout to 30s (prevents intermittent failures under load)
• Fixed Aegis LOW: added allowlist validation for piCmd in pi.ts

v2.0.3 — Fix Pi extension loading

Fixes

• Pi extension loading: added "pi": { "extensions": ["./dist/index.js"] } to package.json — Pi requires this key to discover and load the extension; without it the package is installed but silently ignored
• Built JS: Pi loads compiled JavaScript, not TypeScript source. Added esbuild build step with prepublishOnly hook and CI build step
• Pi tool API: fixed handler → execute(_toolCallId, params) and added required label field
• Pi hook API: fixed event names (before_agent_start, session_compact) and system prompt injection (return { systemPrompt })
• Pi CLI installer: correctly uses pi install npm:@rohirik/pi-ltm (previous fix in 2.0.2)

v2.0.2 — Fix Pi extension installer

Fixes

• Pi extension installer: bunx @rohirik/ltm-core --pi now correctly calls pi install npm:@rohirik/pi-ltm instead of writing to config.toml (which Pi does not read for extensions). The extension is now registered in ~/.pi/agent/settings.json as Pi expects.