Skip to content

Releases: TheSylvester/crispy-recall

v0.3.1 — atomic staging hotfix

Choose a tag to compare

@TheSylvester TheSylvester released this 11 Jul 15:56

Hotfix: upgrade segfault on Linux (0.2.x → 0.3.0)

The 0.3.0 installer could SIGSEGV mid-recall install when upgrading from 0.2.x on Linux, leaving capture hooks disabled until re-run.

Root cause: the installer's upgrade probe dlopens the staged better_sqlite3.node into its own process; staging then rewrote that same live-mapped file in place with copyFileSync. The implicit truncate discards the mapping's relocated pages (Linux truncate semantics zap private COW pages too), so the next GC weak-callback jumps through an unrelocated GOT slot — a deterministic crash, landing after hooks were already quiesced.

Fix: all ~/.recall/bin staging is now atomic — byte-identical files are left untouched; otherwise the new bytes land via a sibling temp file + rename, so live mappings keep their inode. The Windows fallback (for a mapped destination that refuses replacement) rolls the previous file back if landing the new one fails, so the binding is never left missing. Stale staging leftovers are swept on the next install.

Who should upgrade: everyone on 0.3.0, and especially 0.2.x users on Linux who haven't upgraded yet — with this release, npm install -g crispy-recall && recall install upgrades cleanly.

If a previous 0.3.0 upgrade attempt crashed on you: run recall install again — it completes the migration and restores your hooks, then recall doctor to confirm green.

v0.3.0

Choose a tag to compare

@TheSylvester TheSylvester released this 11 Jul 00:37

Minor release over 0.2.1.

Highlights

  • Codex lifecycle hooks — Stop/SubagentStop indexing now runs for Codex too, when Codex is detected.
  • Daemonless query-embedding coordinator — concurrent searches across processes share one embedding path, with no resident daemon.
  • Opaque, round-trippable IDs — new recall read and recall search subcommands; UUIDs, agent-<hex> leaves, and codex-jsonl-* messages all resolve by full ID or literal prefix.
  • Agent-leaf messages are durable but excluded from default search — subagent transcripts stay readable by explicit ID; the parent thread's narration remains the canonical memory.
  • Attended, WAL-safe retrieval-class DB migration — runs on the first recall install after upgrading, writes a recall.db.pre-retrieval-<stamp> rollback snapshot, and re-embeds in the background.
  • Enriched statusline — the optional line shows git branch, model, and context usage alongside the session-id chip.
  • Installer hardening — supported-Node-range preflight, failure recovery, and lazy migration loading.

Upgrading

Close active Claude Code and Codex sessions, then make recall install the first recall command you run after upgrading:

npm install -g crispy-recall
recall install

See the README "Upgrading" section for the migration and snapshot details. Don't downgrade to <=0.1.6 after converting the database.

v0.2.1 — macOS install support

Choose a tag to compare

@TheSylvester TheSylvester released this 07 Jul 02:18

Fixes the macOS install path for 0.2.0's native SQLite engine — the first release verified green end-to-end on Apple Silicon.

Highlights

  • macOS install support. 0.2.0 shipped the native better-sqlite3 + WAL engine without ever running on Apple hardware. 0.2.1 fixes the macOS install path and validates it end-to-end on Apple Silicon (M2 Pro, macOS 26, Node 26):
    • Pre-flight macOS-version check — the bundled llama.cpp embedding binaries need macOS 14+ on arm64 (13.7+ on Intel); older systems now get a clear message instead of a late failure.
    • Upgrade-stable Node path — in-place upgrades no longer pin a Homebrew Cellar path that a later brew upgrade node removes.
    • Node 23 is rejected up front (it has no prebuilt SQLite binding) with an explanation, instead of failing late.
    • The staged SQLite binding is load-verified before the installer trusts it.
  • recall install no longer hangs during setup. Extraction of the embedding binaries is now time-boxed with a fallback to the OS unzip tool (unzip / ditto / Expand-Archive), so a stalled extract can no longer wedge the installer.

Non-macOS installs are unaffected. There are no database or index changes — upgrading from 0.2.0 is just:

npm install -g crispy-recall
recall install

v0.2.0 — Native SQLite (real WAL), embedding v3, git provenance

Choose a tag to compare

@TheSylvester TheSylvester released this 05 Jul 03:58

Native SQLite engine with real WAL, an upgraded embedding pipeline, and git provenance for your sessions.

Highlights

  • Native SQLite with real WAL. The index now runs on better-sqlite3 with write-ahead logging instead of the previous WebAssembly binding — which never actually engaged WAL and could silently corrupt the index when multiple processes wrote at once. That failure mode is eliminated at the root. recall doctor gains a SQLite-binding health section. Node.js ≥ 22.16 is now required.
  • Git provenance: --commit and --blame. recall --commit <hash> lists the session(s) that produced a commit; recall --blame <path>[:line[-line]] traces a file or line range back to the conversations responsible. Matching is structural (your sessions' actual edits vs the commit's diff), not timestamp-based.
  • Better semantic retrieval (embedding v3). Stored messages and queries now carry the task prefixes the embedding model was trained on, and short turns (one-line answers, approvals, decisions) are embedded together with their preceding context so they're finally findable by meaning. Measurably improves retrieval on the LoCoMo benchmark (recall@5 54.9 → 58.4).
  • Semantic search stays available during migrations. Upgrading re-embeds your history in the background; until it finishes, search transparently blends old- and new-format vectors and tags output with (migrating: N% re-embedded) instead of going dark.
  • Relevance-first ranking. The hidden age penalty is off by default — older sessions now rank purely by relevance. Pass --recent to prefer newer sessions explicitly.
  • Faster indexing on large databases. A new index removes a full-table scan from every embedding batch and end-of-turn catch-up (~0.3 s → ~0.05 s at ~287K messages).
  • Safe in-place upgrade for existing installs. recall install migrates an existing database in place: rollback snapshot → WAL conversion → integrity check with auto-repair → background re-embed.
  • New scripting flags. --raw-messages (full ranked per-message JSON) and --no-idf (keep common words in keyword search).

Upgrading from 0.1.x

Exit any running Claude/Codex sessions, then:

npm install -g crispy-recall
recall install   # run this FIRST, before any other recall command

Your indexed history is preserved — even without the original transcripts (Claude Code deletes session .jsonl files after 30 days by default; the migration never reads them). A rollback snapshot is written to ~/.recall/recall.db.pre-upgrade-<stamp>. The migration is one-way — don't downgrade to ≤ 0.1.6 afterwards. See the README for full upgrade notes.

v0.1.6 — lean install, no redundant deps

Choose a tag to compare

@TheSylvester TheSylvester released this 14 Jun 22:34

Install hygiene — no code changes

npm install -g crispy-recall now installs 1 package with 0 vulnerabilities, down from ~150 packages that included a deprecated glob and the Agent SDK's transitive moderate advisories (hono, @anthropic-ai/sdk).

Root cause: esbuild bundles every runtime library into dist/ at build time (bundle:true, external:[]), and the Agent SDK is imported for TypeScript types only. So the published dist/ was already self-contained — those libraries never needed to be installed at runtime. Moved all six from dependencies to devDependencies.

The runtime bundle is byte-identical to v0.1.5; this is purely install-time dependency hygiene. No behavior changes.

Verified

  • Clean tarball install: 1 package added, no deprecation warnings, binary runs
  • npm audit --omit=dev: 0 vulnerabilities (was 3 moderate)
  • Bundle runs standalone with no node_modules

v0.1.5

Choose a tag to compare

@TheSylvester TheSylvester released this 13 Jun 19:19

Fix: backfill now derives project_id from each transcript's own cwd, so sessions indexed before install are visible to the default project-scoped search. Previously every backfilled session was stored with project_id = NULL and silently hidden — recall appeared to start at install day.

Docs: document --all / --project search scoping (skill + README), fix the recall usage example, and tighten the privacy note.

v0.1.4 — Windows transcript discovery fix

Choose a tag to compare

@TheSylvester TheSylvester released this 31 May 15:10

Fixes

  • discovery: transcript discovery built its glob patterns with path.join, which emits backslashes on Windows. The glob library treats \ as an escape character, so C:\Users\…\.claude\projects\**\*.jsonl matched nothingbackfill and the steady-state mtime-scan found 0 transcripts on Windows-native, even though install, GPU/CUDA staging, and the Stop hook all looked healthy. Fixed with a shared transcriptGlob() helper that joins segments with / and normalizes any backslashes the root carries (the same normalization the Stop hook already applies to transcript_path). Real-time Stop-hook ingestion was unaffected; only the bulk discovery paths were broken.

Verified end-to-end on Windows-native (RTX 2060): 289 messages discovered (was 0), 245 embedded on GPU via flash-attention (-fa -ngl 999), semantic search returns results. WSL/Linux/macOS unaffected.

CUDA backend asset is byte-identical to v0.1.0–v0.1.3 (llama.cpp b5300).

v0.1.3

Choose a tag to compare

@TheSylvester TheSylvester released this 31 May 09:05

Fixes

  • gpu: enable Flash Attention (-fa) for the embed server, the one-shot path, and the install probe. The 8192-token attention compute buffer is otherwise O(n²) (~3.7 GB on GPU → ~5.7 GB total), which OOMs cards <6 GB and forces CPU fallback. -fa makes it O(n) (~0.8 GB → ~2.9 GB total), so 4 GB GPUs now run on GPU at the full 8192 context. Embeddings are numerically identical (verified cosine 1.0 vs non-FA) and throughput improves (~26 → ~32 msg/s on an RTX 2060). The probe must mirror runtime, or it OOMs on a 4 GB card and falsely rejects a working GPU.

Builds on v0.1.2 (bin/ CUDA staging, real-device probe, embed resilience, codex array output). CUDA backend asset is byte-identical (llama.cpp b5300).

v0.1.2

Choose a tag to compare

@TheSylvester TheSylvester released this 31 May 08:46

Fixes — GPU embedding backfill

  • installer (gpu): stage libggml-cuda.so into bin/ beside the executable (not a separate bin-cuda/). llama.cpp's GGML_BACKEND_DL loader discovers backends by scanning the executable's own directory, not LD_LIBRARY_PATH — so the CUDA backend never loaded and embedding silently ran on CPU (while still printing offloaded N/N layers to GPU). Matches the Windows path.
  • installer (gpu probe): require a real CUDA device marker (ggml_cuda_init / loaded CUDA backend / CUDA0 buffer) instead of the offloaded N/N string, which prints even on CPU and caused the installer to falsely persist mode=gpu.
  • embed: per-item fallback so a single message exceeding the 8192-token physical batch can't 500 the whole batch and wedge the backfill.
  • codex: handle array-valued function_call_output (image/screenshot results) without crashing the session ingest (output.match is not a function).

Net effect on an RTX 2060: embedding goes from ~5 msg/s (silent CPU, stalling) to ~26 msg/s at 80–96% GPU utilization.

CUDA backend asset is byte-identical to v0.1.0/v0.1.1 (llama.cpp b5300).

v0.1.1

Choose a tag to compare

@TheSylvester TheSylvester released this 31 May 06:41

Fixes

  • installer: resolve symlinked argv[1] so the bundle scripts (recall.js, stop-hook.js, embed-pending.js) stage into ~/.recall/bin/ under a global npm install -g layout. Previously dirname(argv[1]) stopped at the symlink's bin/ dir, staging silently no-oped, and the wired Stop hook pointed at a missing stop-hook.js — breaking real-time ingestion for every global install.

The bundled CUDA backend asset is byte-identical to v0.1.0 (llama.cpp b5300, recall-version-independent).