OpenAgentMemory: Archive and Search Your AI Coding Sessions Locally

Modern AI coding work rarely lives inside a single tool. A developer might plan a refactor in Claude Code, run a quick fix in Codex, and let OpenCode handle something else the next day. Each of those sessions is a detailed record of how a problem was actually solved: the prompts, the reasoning, the diffs, and the commands that worked. That record is often more useful than the final commit message, because it captures the thinking and the dead ends, not just the result.

The problem is that this history is both valuable and fragile. Every tool stores its logs in its own format and its own directory, those files rotate or get cleaned up, and the record can vanish when you reinstall a tool or move to a new machine. The notes on how you solved a hard problem last month may already be gone. OpenAgentMemory, also published as AyeMemory, is an open-source project that targets exactly this: it archives the session logs from several AI coding tools into one local, searchable database designed to outlive the tools themselves.

What OpenAgentMemory Does

OpenAgentMemory describes itself as a local-first archive and full-text search tool for AI coding-tool sessions. According to its README, it reads logs from Claude Code, Codex, and OpenCode, normalizes them into a shared session and message format, and stores everything in a single SQLite database on your own machine. Support for Gemini CLI and Trae is listed as planned rather than shipped.

Two design choices define the project. The first is local-first: all data stays on your computer, and nothing is sent to an external service. The second is read-only: the tool only reads the source log files and never modifies or moves them, so it is safe to run alongside a live coding session. That positioning puts it in the same territory as the open-source and local AI tools we have covered before, where data ownership and privacy are the whole point rather than a side feature.

Why a Durable Session Archive Matters

The case for keeping a session archive comes down to three recurring needs. The first is recall across tools. Once your work is spread over several agents, no single tool can answer "how did I fix that authentication bug three weeks ago?" A unified archive can, because it holds every session in one place regardless of which tool produced it.

The second is durability. Tool log directories are not built to be permanent. They are working state, and they get rotated, truncated, or deleted. An archive that captures sessions as they happen turns that disposable working state into a record you can rely on later.

The third is searchability. A folder full of JSONL files is technically a record, but it is not a usable one. Full-text search over a normalized database is what makes months of accumulated sessions actually answerable. This is the same instinct behind a knowledge base or RAG workflow: raw text only becomes useful once you can retrieve the right part of it on demand.

How It Works

The architecture is small and easy to follow, which is part of its appeal. At the edge sit adapters, one per supported tool. Each adapter implements two functions: discover(), which finds the relevant log files on disk, and parseFile(), which turns a file into normalized session and message records. Claude Code logs live under the project's JSONL files, Codex stores its own JSONL sessions, and OpenCode keeps its data in a SQLite database, so each adapter knows how to read its tool's native format.

Those normalized records flow into an ingest engine that handles incremental syncing, de-duplication, and full-text indexing. The archive itself is a SQLite database stored at ~/.ai-sessions/archive.db, with an FTS5 full-text index layered on top. On the output side, a command-line interface and a small REST API built with Hono expose the archive, and a React plus Vite web UI provides a three-column view: filters on the left, a session list in the middle, and the full message thread on the right. Search hits are highlighted inline so you can see why a session matched.

The Design Rules That Keep the Archive Trustworthy

What makes an archive tool dependable is not its feature list but the invariants it refuses to break, and OpenAgentMemory is explicit about its own. Adapters are strictly read-only. They never write to or move the source files, which is what makes the tool safe to run while a coding agent is active.

The archive is append-only in spirit. When a source file disappears, its sessions are not removed from the database; they are flagged as deleted and kept. The archive is meant to outlive the tools, so removing the original should never erase the history.

Sync is incremental and idempotent. JSONL files are read from a stored byte offset, so re-running a sync appends only what is new and never duplicates what already exists. You can run it on a schedule or by hand without worrying about corrupting the archive.

The raw record is preserved. Each message keeps its verbatim source, so if a tool changes its format, everything can be re-derived from the original rather than lost in a lossy conversion. These are exactly the kinds of guarantees that separate a real archive from a folder of exports, and they echo the evidence-first standard described in our editorial policy.

Getting Started

Setup follows the usual Node project pattern. After cloning the repository, you install dependencies and run a sync, which discovers and archives sessions from every installed tool it supports:

npm install

npm run sync

From there, a handful of commands cover daily use. The list command shows the most recent sessions with their source, message count, and title. The search command takes a query, runs a full-text search, and returns the top hits with matches highlighted. The serve command starts the REST API so the web UI, run separately, can browse and search the archive in a browser. Because it is a self-hosted tool, you run and maintain it yourself, which is the trade-off behind keeping all the data local.

Who It Is For, and What to Check

OpenAgentMemory will appeal most to developers who already work across more than one AI coding agent and who treat their session history as something worth keeping. If you use a single tool occasionally, its built-in history is probably enough. If you run several coding assistants and want one durable, private, searchable record of all of them, a tool like this fills a real gap.

A few caveats are worth keeping in mind. It is an open-source project under active development, so features such as Gemini and Trae support are planned rather than finished, and details may change. Because adapters depend on each tool's log format, an upstream format change can require an adapter update, which is the maintenance cost of a self-hosted approach. And as with any tool we cover, treat the specifics here as a snapshot: check the current project README for the latest supported tools, commands, and behavior before relying on it. For readers who value keeping their AI workflow data on their own machine, it is a focused example of the local AI tooling trend applied to a genuinely useful problem.