memsearch - Moses Yebei

The Problem

AI coding agents (Claude Code, Codex, OpenClaw, OpenCode) each maintain isolated session context. Knowledge gained in one agent—project conventions, user preferences, resolved debugging paths—is lost when switching tools or starting a new session. Memsearch solves this by providing a persistent, unified memory layer that all agents can read and write, backed by human-readable Markdown files with a Milvus vector index for semantic retrieval.

What This Does

Memsearch indexes agent transcripts into Markdown memory files, then provides semantic search across them. The src/memsearch/ package contains the core engine: cli.py (entry points), core.py (indexing orchestration), store.py (Milvus vector store), chunker.py (Markdown chunking), and embeddings/ (multiple provider adapters: OpenAI, Google, Jina, Mistral, Ollama, ONNX, Voyage).

The plugins/ directory contains per-agent integrations. Each plugin (e.g., plugins/claude-code/, plugins/codex/) has hooks that capture conversation transcripts, scripts to run maintenance tasks, and skills for memory recall. A shared plugins/_shared/scripts/maintenance-runner.py handles background memory distillation across all agents.

How It Is Wired

Execution starts at src/memsearch/cli.py. The index command (line 186) reaches 67 functions; skills_distill (line 1178) reaches 108. The call graph shows MemSearchConfig is called from 31 places, resolve_config from 19, and chunk_markdown from 17—these are the highest-blast-radius functions. The MilvusStore is called from 11 places.

A typical index run traces: index -> _index_file -> chunk_markdown -> embed -> batched_embed (9 call sites), then writes to Milvus via MilvusStore. The compact command reaches _compact_openai via OpenAI's async client—a model inference call. watch (line 522) runs a filesystem watcher that triggers re-indexing on file changes.

The module graph shows src/memsearch/core has instability 0.82 (9 imports out, 2 in)—it's a hub that everything depends on but that depends on little itself. src/memsearch/embeddings/utils is the opposite: 8 modules import it, it imports nothing.

How To Use It

# Clone and install
git clone https://github.com/moses-y/memsearch
cd memsearch
pip install -e .  # from pyproject.toml

# Index your agent transcripts
memsearch index --path /path/to/transcripts

# Search across all memories
memsearch search "how did we handle the database migration?"

Configuration lives in src/memsearch/config.py—environment variable resolution and plugin config merging. Agent-specific installers exist in plugins/<agent>/install.sh. The CLI entry point is src/memsearch/__main__.py.

Real-World Use

A team runs Claude Code for day-to-day coding and Codex for one-off refactors. Each agent's transcripts are indexed into the same memory store. A developer asks Claude Code "what's the pattern for our API error handling?"—it retrieves the answer from a Codex session from three weeks ago. The skills_distill command turns repeated workflows into reusable skills (src/memsearch/skills.py), so the team's standard deployment procedure becomes an installable skill both agents can invoke.

Code Health & Issues

Static analysis found 50 issues (2 high, 48 medium). Key findings:

High - eval() over a runtime value in plugins/opencode/index.ts—executes arbitrary computed strings.
High - GitHub Actions pinned to mutable tags (astral-sh/setup-uv@v7) instead of commit SHAs—a supply-chain risk.
Medium - Broad exception handling across 9 files (src/memsearch/store.py, maintenance runners)—swallows errors indiscriminately.
Medium - 782 duplicated code blocks across 44 files, primarily in maintenance-runner.py variants. The _strip_jsonc/_read_jsonc_config functions are copy-pasted across plugins.
Medium - Deep nesting (max depth 6) in store.py, maintenance.py, and tests.
Medium - No dependency vulnerability scan in CI; no Dependabot/Renovate configured.
Low - No lockfile for Python or Node dependencies—non-reproducible builds.

The repo has 33 test files and GitHub Actions CI, but the duplicated maintenance runner logic across 44 files is the clearest refactoring target.

The Bottom Line

Memsearch is a well-architected solution to a real problem—cross-agent persistent memory. The Markdown-as-source-of-truth design is sensible, and the plugin ecosystem covers the main agents. The duplication in plugin maintenance scripts and the eval() usage need attention before production use. For teams running multiple AI coding agents, this is worth evaluating.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

201 files

Python67
Markdown56
Shell20
YAML12
JSON6
TypeScript3

React

Module dependencies

The 10 most depended-upon modules of 70, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_c_memsearch_embeddings_utils["utils"] n1_src_memsearch_config["config"] n2_src_memsearch_compact["compact"] n3_src_memsearch_index_report["index_report"] n4_src_memsearch_io["io"] n5_src_memsearch_core["core"] n6_emsearch_embeddings___init__["__init__"] n7_src_memsearch_store["store"] n8_src_memsearch_maintenance["maintenance"] n9_src_memsearch___init__["__init__"] n9_src_memsearch___init__ --> n5_src_memsearch_core n2_src_memsearch_compact --> n1_src_memsearch_config n1_src_memsearch_config --> n6_emsearch_embeddings___init__ n5_src_memsearch_core --> n2_src_memsearch_compact n5_src_memsearch_core --> n6_emsearch_embeddings___init__ n5_src_memsearch_core --> n3_src_memsearch_index_report n5_src_memsearch_core --> n4_src_memsearch_io n5_src_memsearch_core --> n7_src_memsearch_store n8_src_memsearch_maintenance --> n2_src_memsearch_compact n8_src_memsearch_maintenance --> n1_src_memsearch_config n8_src_memsearch_maintenance --> n4_src_memsearch_io

Dependencies

5 of 11 declared dependencies are a major version behind. Resolved 11 of 11 against the registry.

Package	Declared	Latest	Behind
`setuptools`	>=78.1.1,<81	84.0.0	6 major
`watchdog`	>=4.0	6.0.0	2 major
`openai`	>=1.0	3.1.0	2 major
`pymilvus`	>=2.5.0,!=2.6.10	3.0.1	1 major
`milvus-lite`	>=2.5.0; sys_platform !=	3.2.0	1 major

Findings

LowDependencies declared without a lockfile - non-reproducible builds plugins/openclaw/package.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium3

low1

Pin third-party GitHub Actions to a commit SHAhigh3 occurrences

.github/workflows

astral-sh/setup-uv@v7, release-drafter/release-drafter@v6, pypa/gh-action-pypi-publish@release/v1

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Remove eval over a runtime valuehigh

plugins/opencode/index.ts

exec() over a computed value

eval executes whatever the string contains, so wherever that string came from is now able to run code in the process, and the distance between the input and the eval is usually the only thing making it look safe.

Fix: Parse the value into the type you expect, with json.loads or ast.literal_eval.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/release.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/lint.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.