Lossless archive and search for AI agent sessions across clients, exposed to agents over MCP.
io.github.tenequm/pond MCP Server
The io.github.tenequm/pond MCP server provides lossless archiving and search for AI agent sessions across clients, exposed to agents over MCP. It is associated with session-logs and supports storage and retrieval workflows that rely on vector search and full-text search (fts).
๐ ๏ธ Key Features
Lossless archive of AI agent sessions across clients
Search over archived sessions
Exposure to agents via MCP
Uses topics including vector-search and fts
๐ Use Cases
Persist and query agent session logs across different clients
Retrieve prior session context for agents
Support developer workflows involving session memory and searchable logs
โก Developer Benefits
Structured access to session data through MCP
Enables both vector-search and full-text search approaches
Topics indicate compatibility with agent tooling ecosystems (e.g., session-logs, memory)
โ ๏ธ Limitations
Tool availability details are not provided in the available source data (toolCount not included).
"I know we discussed that before. Why can't I find that damn conversation?"
Pond makes every AI agent session you've ever run - Claude Code, Codex, any tool, any machine - searchable in one place.
Your agent history is already on your disk: thousands of sessions full of decisions, fixes, and dead ends - scattered across tools that can't search them. Pond ingests them all automatically and losslessly into storage you own (a local dir or your own S3 bucket), makes the whole corpus searchable and SQL-queryable, and hands that recall back to your agents over MCP - so "how did we fix this before?" is a query, not an archaeology dig. Sessions stop being locked to the tool that created them: any session can be restored into any supported client and continued there.
sh
brew install tenequm/tap/pond # macOS / Linux
scoop bucket add tenequm https://github.com/tenequm/scoop-bucket # Windows
scoop install tenequm/pond
Or prompt your agent: "Please install and set up pond (see github.com/tenequm/pond)" - the full, failure-proofed version of that prompt is in Connect your agents.
A live 12k-session corpus, then a three-month-old fix found and verified against the current code (crisper MP4)
Five real recall questions, one corpus, one machine - method, raw numbers, and a rerunnable script in docs/benchmarks
Status: pre-v1. Schemas, wire shapes, and config keys are subject to breaking change until v1. Full documentation lives at pond.locker; the contract is docs/spec.md.
Quickstart
Install, run guided setup, and ingest your local sessions:
sh
brew install tenequm/tap/pond # macOS / Linux; Windows: Scoop or a release zip - see Install below
pond init # guided setup: storage, adapters, MCP + agent skill, optional schedule
pond sync# ingest and index - every enabled adapter
pond init registers pond as an MCP server for Claude Code and installs the bundled pond skill; for Codex it prints the command to run instead - restart the client afterwards so the tools load. By hand: claude mcp add -s user pond -- pond mcp, codex mcp add pond -- pond mcp; skill: mkdir -p ~/.claude/skills/pond && pond skill > ~/.claude/skills/pond/SKILL.md (that whole line is POSIX-only - mkdir -p, &&, and > all break or corrupt in Windows PowerShell 5.1; use the PowerShell block in Connect your agents). Then ask your agent - real prompts from daily use:
code
check in pond how we solved this before, then apply the same fix here
code
where we left off yesterday - check pond, then continue
code
are you sure that won't break X? check in pond how we struggled with exactly this
Sessions are picked up automatically from Claude Code, the Claude desktop app (local agent mode), Codex CLI, opencode, pi-coding-agent, oh-my-pi, OpenClaw, NanoClaw, Hermes Agent, letta-code, grok-build, and Antigravity CLI (agy, including its ACP server). A Claude.ai data export imports with pond sync claude-ai-export --path <path> (manual download, so not auto-discovered).
Isn't this another memory tool?
No - it's the layer underneath one. Memory tools store what they decided you'd need - facts, summaries, filed chunks; the sessions themselves are gone. Pond keeps the sessions: every message, tool call, and result, value-complete, cross-client, in storage you own, never pruned - searchable over MCP and restorable into any client. Memory is a derived view you can always rebuild from an archive; an archive can never be rebuilt from memories.
Three kinds of tool get called "memory". Side by side:
pond
Session search (ctx, deja-vu, cass)
Memory layers (Mem0, Letta)
History from before install
yes
yes
no
What is kept
the whole session
a search index ยน
extracted facts
Where it lives
local dir or S3 bucket
local index
the tool's database
After the harness deletes the file
still there
gone at next refresh ยน
only the extract
Several machines
one shared bucket
pulled into one machine ยฒ
shared server or cloud
Agent access
CLI, MCP, HTTP, SQL
CLI, MCP ยณ
HTTP, SDK, MCP
ยน cass also mirrors the raw files, so they outlive the source. ยฒ deja-vu copies records between machines over ssh; cass pulls other hosts' session files over ssh/rsync into its local index; ctx is single-machine. ยณ cass has no MCP server.
Pick session search for fast local recall. Pick a memory layer when the agent should carry distilled facts, not the record. Pick pond when you want the sessions themselves, in storage you own, from every machine you run.
Full comparison, with receipts per tool: pond.locker/compare. Every cell is a claim about a specific version of someone else's project. If one has gone stale, open an issue and it gets fixed the same day.
Background
Every agentic CLI ships its own session format and its own search surface. Switching tools means losing history. Replaying a Claude Code session in another provider's tooling means re-translating the wire shape by hand. Hosted multi-tenant deployments rebuild the same storage layer from scratch.
Pond is the storage and retrieval layer that sits underneath. Every adapter is a bidirectional codec between a client format and one canonical schema, so any session can be restored by any adapter - it need not return to the client that produced it. Storage, search (BM25 full-text by default, with optional semantic search, one arm per query), and provider-agnostic replay all sit on a single Lance-on-object-storage foundation.
The v1 surface includes: full CLI, HTTP+JSON and MCP transports, search over three Lance datasets, opt-in intfloat/multilingual-e5-small embeddings at FP16 weights (Metal on macOS, CUDA opt-in, CPU fallback), and local-FS / S3 / GCS / Azure backends through Lance's object_store integration.
Then open a new terminal - PATH changes reach only processes started after the install. See the Windows notes for Defender, long paths, scheduling, and WSL.
No package manager (any platform): every release attaches prebuilt binaries (pond-x86_64-pc-windows-msvc.zip on Windows, ~223 MB unpacked) - unpack one and add its directory to PATH (on Windows: Settings > System > About > Advanced system settings > Environment Variables, under your user variables), nothing else to install.
Via cargo (any platform, needs the Rust toolchain):
sh
cargo binstall pond-db # downloads the prebuilt binary (needs cargo-binstall)
cargo install pond-db # builds from crates.io (installs the `pond` command)
Both install pond.exe only, so scheduled sync on Windows - which runs through pondw.exe - wants the Scoop or zip install instead (or --features windows-launcher on a source build). cargo install also needs the protoc and NASM prerequisites below.
Build from source:
sh
git clone https://github.com/tenequm/pond.git
cd pond
cargo install --path packages/pond
On Windows that clone needs git config --global core.longpaths true first (test-fixture paths exceed 260 characters), and the build needs an explicit --target x86_64-pc-windows-msvc - without it cargo applies the repo's +crt-static flag to build scripts and proc-macros too, which then fail to load.
For CUDA acceleration on Linux:
sh
cargo install --path packages/pond --features cuda
On macOS the Metal backend is selected automatically; on other systems the CPU fallback runs without extra features. Building from source on Windows additionally needs protoc (winget install Google.Protobuf) and NASM (winget install NASM.NASM, then add C:\Program Files\NASM to PATH yourself - its installer doesn't) on PATH.
Set up storage, adapters, MCP registration, and an optional sync schedule in one pass (idempotent - re-run it any time to repair or update):
sh
pond init
Then import sessions from local adapters, update indexes, and search:
sh
pond sync
pond search "how did we wire up the OCC retry loop"
Run a server
sh
pond serve # HTTP on 127.0.0.1:9797
pond serve --transport stdio # MCP over stdio
pond mcp # alias for stdio MCP
Fetch and copy
Fetch a single session or message, or move a whole corpus:
sh
pond get-session <id>
pond get-message <id>
pond copy --from local --to snapshot.pond
pond copy --from snapshot.pond --to local
Read-only SQL
Ask structured questions with read-only SQL (the same surface as the pond_sql MCP tool):
sh
pond sql "SELECT project, count(*) FROM messages GROUP BY project ORDER BY 2 DESC"
Maintenance
Run maintenance on demand (sync folds indexes on every run):
sh
pond optimize --only embed # only when [embeddings].enabled = true
pond optimize --only index
Scheduled sync
Keep pond current automatically (launchd on macOS, systemd user timers or cron on Linux, Task Scheduler on Windows - there, run it from a normal shell, not an elevated one, or the task ends up owned by Administrators):
sh
pond schedule start # every 5m by default (--every 15m|1h|6h|1d)
pond schedule status
pond schedule logs
Status and introspection
pond status prints a per-table storage table, then indexes (text readiness, plus the semantic half only when embeddings are enabled), stored (sessions + messages), agents (source agents in the store), and this host's view of it: per-adapter sessions pending sync, the last sync's outcome (including a surfaced failure from a scheduled run), and the next scheduled run. pond status --hosts breaks a shared store down by ingest host; --include-subagents counts each subagent as its own agent. pond sync --dry-run previews what the next sync would read. pond search --explain returns Lance's analyze_plan output for each retrieval arm.
Remote storage
By default pond stores data locally under ~/.local/share/pond (%LOCALAPPDATA%\pond\data on Windows). To use an object store, add credentials and switch the destination:
pond init --storage-path <url> configures a remote destination during setup and prompts for credentials inline when the destination is remote, so a bucket is one command. The s3+https://host/bucket form works for any S3-compatible store (Hetzner, R2, B2, MinIO); s3://, gs://, and az:// use the standard cloud SDK credential chain when no [creds.*] set matches. pond copy --from <local> --to <url> carries existing local data into the bucket - idempotent, never deletes the source, and on completion it rebuilds the destination indexes and verifies every row landed (exit 6 if any are missing or duplicated, so you never reconcile by hand). pond copy --verify-only --from <local> --to <url> runs that same check read-only, without copying. Full walkthrough: pond.locker.
Configuration
pond init walks through everything below interactively and enables the adapters it finds. pond sync only ingests already-enabled adapters - enabling one is an explicit step (pond adapters enable / pond adapters discover / pond init), never a side effect of sync. Config lives at ~/.config/pond/config.toml on macOS and Linux, %APPDATA%\pond\config.toml on Windows (pond config path prints it). Every [adapters.<name>] block needs enabled = true to be active; sections without it (or with enabled = false) are skipped. ~ in paths expands on every platform (%USERPROFILE% on Windows).
toml
[adapters.claude-code]enabled = truepath = "~/.claude/projects"[adapters.codex-cli]enabled = false# kept in config, skipped on `pond sync`path = "~/.codex/sessions"
Search is BM25 full-text by default. Semantic search is opt-in and off unless you ask for it: with it off no pond process downloads or loads an embedding model, new messages get no vectors, and --mode vector is refused. Turn it on in config or with POND_EMBEDDINGS_ENABLED=true, then run pond optimize --only embed once to fill the backlog:
toml
[embeddings]enabled = true
Full detail, including what it costs and how mixed fleets behave, is in the configuration reference.
Supported harnesses
One adapter per harness, in pond adapters discovery order; Reads is the path pond init discovers and writes to [adapters.<name>].path - shown POSIX-style, with the same home-relative layout on Windows (~/.claude/projects is %USERPROFILE%\.claude\projects). Last verified is the most recent capture or refresh date of the adapter's committed fixture (packages/pond/tests/fixtures/adapter/), the corpus its mapping is tested against. Adapters are maintained best-effort, and format drift is safe by design: unknown record shapes still ingest losslessly, malformed input surfaces as a typed error naming the file. Adding a harness is routine work - see Contributing.
Adapter
Reads
Last verified
claude-code
Claude Code CLI, ~/.claude/projects
2026-08-14
claude-desktop-app
Claude Desktop / Cowork local agent sessions
2026-05-13
claude-ai-export
claude.ai data-export archive (manual --path)
2026-06-04
codex-cli
OpenAI Codex CLI, ~/.codex/sessions
2026-09-01
opencode
opencode, ~/.local/share/opencode (SQLite DB + legacy tree)
2026-07-14
openclaw
openclaw, ~/.openclaw
2026-05-13
nanoclaw
nanoclaw, ~/nanoclaw (the install root holding data/v2-sessions)
2026-05-14
hermes
Hermes Agent, ~/.hermes (state.db per profile)
2026-07-23
pi-coding-agent
pi, ~/.pi/agent/sessions
2026-08-06
oh-my-pi
oh-my-pi, ~/.omp/agent/sessions (ingest-only)
2026-08-14
letta-code
letta-code, ~/.letta/transcripts (a root relocated via LETTA_TRANSCRIPT_ROOT is configured as an explicit path)
2026-08-24
grok-build
grok-build (xAI grok CLI), ~/.grok/sessions (a relocated GROK_HOME is configured as an explicit path)
2026-08-24
agy
Antigravity CLI and its ACP server, ~/.gemini (both antigravity-cli/ and antigravity-acp/; a relocated GEMINI_HOME is configured as an explicit path; ingest-only)
2026-09-10
Verbosity
Root-level -v / -vv / -vvv raise the tracing level (info / debug / trace); -q / -qq lower it. The default surfaces warnings only. RUST_LOG overrides the CLI flag when set; POND_LOG is no longer honored.
Design
The full contract is in docs/spec.md. Key choices:
Lance direct, no wrapper. The lance-format/lance crates are the only storage and search engine. No lancedb, no parallel abstraction. Storage, indexing, OCC, schema evolution, blob columns, versioning, and time-travel are all Lance. The read-only pond sql surface is DataFusion planning over the same Lance datasets - a query escape hatch, not a second engine.
Canonical Session / Message / Part interlingua. Owned in pond, in the shape of Effect v4's Prompt-side Part union. This schema is pond's product; everything else is machinery around it.
Three Lance datasets (sessions, messages, parts). messages carries the nullable embedding (vector + embedding_model) alongside denormalized filter columns (source_agent / project / role / timestamp) for single-stage filter pushdown.
No-synthesis adapter seam. Adapters parse source records through extractor helpers that make "invent a value" a compile error - model-no-synthesis, model-schema-honesty, and adapter-provenance-required are structural, not review rules.
Index lifecycle decoupled from writes. Writes commit data (including embeddings, computed inline at ingest when embeddings are enabled) without folding the search indexes. pond sync runs index maintenance by default, and pond optimize --only index runs it on demand; Lance merges index results with a flat scan over unindexed fragments, so reads stay correct.
Single-arm retrieval. Each query runs one retriever - fts (BM25, the default) or vector (cosine, with a gentle recency tiebreaker, offered only when embeddings are enabled) - chosen per query; no server-side fusion. --sort-by recency returns newest-first. Results group to one summary per session, keyed on session_root.
Language-neutral full-text. Word-level simple tokenizer with English stemming (ascii-folding on); tokens the stemmer does not recognize pass through unchanged and stay exact-matchable, so pond indexes sessions in any language alike.
Two transports, one handler set. HTTP+JSON (axum) and MCP (rmcp) both dispatch into the same handlers. Wire ops: pond_search, pond_get_session, pond_get_message, pond_ingest. MCP additionally exposes the read-only pond_sql tool and the schema://pond, schema://pond-sql, and stats://pond resources.
Opaque-string multi-tenancy. Each tenant is a namespace string the integrator supplies; pond does not authenticate, authorize, or model identity. The object store's IAM is the storage boundary.
Encryption is operational. Bucket SSE plus filesystem encryption; pond holds no keys and adds no application-level crypto.
Roadmap
pond ships in small steps. This table lists the steps in order. Done steps stay in the table. The roadmap board holds the same items with their issues. React or comment on an issue to influence the order.
#
Step
Status
1
Lossless ingest from Claude Code and Codex into Lance, local or S3
A capture daemon. pond reads what your harness already writes.
โ Not planned
A hosted service that owns your bucket. Your storage stays yours.
โ Not planned
Summaries or pruning of stored sessions. pond keeps the sessions.
โ Not planned
Step 7 was based on data. Over 63 days, agents ran 1,126 searches against this archive. BM25 found the answer 61% of the time. Vector found it 37% of the time. Read the measurement.
This is a direction, not a contract. The order changes when the data changes.
References
The upstream schemas that shaped pond's canonical model are documented in docs/references/ (source URLs + why each matters; the vendored code itself is not redistributed). Real session captures live under packages/pond/tests/fixtures/adapter/.
Pointers to additional reference schemas or session samples worth documenting under docs/references/.
Bug reports against the v1 surface (CLI verbs, wire ops, schema mismatches, OCC behavior, object-store backends).
For something bigger, the roadmap is the list. Comment on the issue before you start, so we agree on the scope. For other larger changes, open an issue first to discuss the direction. For security issues, see SECURITY.md.