I built Darc, an open-source shared memory search tool for coding agents, with a different approach from most agent memory systems we can see today. It is an index + (lexical) search tool over agent session history, rather than a managed memory system. No embeddings, no agent-aided consolidation, no injection hooks.

How it works: Darc archives Codex / Claude Code session rollouts that already exist under ~/.codex and ~/.claude, indexes them into a single SQLite DB, and exposes session/turn/tool call/file-level search commands over them.

Why I built this: I've tried using different agent memory tools and they were useful, but sometimes I found them nosiy. I kept turning memory on/off depending on the task. For example, when I ran iterative code review rounds, I saw reviewer agents report "no findings" with "memory cited" memos, where the cited memory came from recent review sessions or the session that built the feature being reviewed. I believe this could put bias to the current reviewer's context window, and wanted to turn off those "injection hook" memory feature for such cases.

So I came up with an idea. Recent coding agent tools tend do prefer simple lexical search (UNIX tools; `rg`, `sed`, etc.) to semantic search over vector embeddings, and they work quite well and reliably without the heavy embedding. Why don't we take similar approach to agent memories, treating the session history like documents or code?

The idea is to let agents use Darc iteratively to discover relevant evidence or decisions from prior sessions, see which files or sessions are deeply related, and keep chaining the search until they understand the full picture of what happened in the past before they jump into editing code.

I also added team sharing feature to Darc. Users can encrypt (via `age`) and share their indexed agent session history with other team members working on the same project via Git backend of their choice (GitHub or self-hosted Git server). Regex-based redaction is supported by default (so sensitive data like secret keys, API keys or env vars don't get into SQLite at all). Then, users can pull agent session history indexes from other team members and search over them to get decision context made by others. This is analogous to asking colleagues who wrote the code about context behind the work, like design decisions, before touching that part of the code.

That said, it still needs proper evaluation. I'm working on simple bench/evals to compare scenarios like:

- Baseline, with no memory

- Using Codex / Claude Code built-in memory (the native memory system that summarizes prior sessions using background agents and writes MEMORY.md, not merely AGENTS.md or CLAUDE.md)

- Using Darc

- Using Darc + Codex / Claude Code built-in memory

- Just `rg` on session history directly

If this approach sounds interesting (or you think it doesn't make sense) I'd love to hear your feedback. I'd also love to learn what methods people are using to manage team-level context on project where coding agents are used heavily.