deja-vu Syncs Coding Agent Memory

deja-vu is an MIT-licensed Go project by vshulcz that turns local coding-agent chat logs into searchable memory. It deals with a very ordinary agentic coding problem: Claude Code, Anthropic's coding agent, Codex, OpenAI's coding agent, and opencode, SST's terminal coding agent, can solve a bug once and then forget it in the next session. The useful takeaway is simple: when you compare AI code generation tools, also compare what happens to the work after the chat ends. deja-vu makes that question concrete with local search, MCP recall, redaction, sharing, and sync over exported session memory.

Start with the thing already on disk

Coding-agent memory is the reusable record of previous agent sessions: bug hunts, design decisions, failed commands, and fixes that would otherwise live only in chat logs.

The clever bit in deja-vu is that it does not ask you to start fresh. Its README says Claude Code, Codex, and opencode already write conversations to local files, sometimes gigabytes of them. deja-vu indexes those histories after the fact, so old sessions can become useful without moving them into a hosted service.

As of July 2026, the repository shows 222 GitHub stars, is mainly written in Go, and ships as a zero-dependency binary. The project lists topics like ai-agents, claude-code, codex, mcp, and memory, which is a pretty accurate map of the niche it is trying to occupy.

The trap to avoid is treating this as a new agent. It is not. It is a memory layer around session logs that your agents already produce.

Let the agent recall before it re-debugs

deja-vu exposes an MCP recall tool so an agent can ask for relevant previous work. MCP, the Model Context Protocol, is a standard way for coding agents and editors to connect to external tools and context sources. In this case, the external source is your own local agent history.

That matters because a fresh session often wastes its first ten minutes rediscovering facts. The database connection pool was tuned last month. The flaky Playwright test needed a fake clock. The migration failed because the staging schema lagged production by one column.

The README claims text search in the 7–9 ms range over gigabytes of logs, plus auto-recall through a SessionStart hook. That hook is the spicy part: relevant memory can land in context before you remember to ask for it.

The trap is over-context. A memory system that dumps every old tangent into the prompt is just another source of noise. For a Cursor, Anysphere's AI code editor, workflow, this is where a small repository rule helps: recall is allowed, but the agent must cite the recalled session summary before changing code.

---
description: Use recalled agent memory safely when editing this repo
globs:
  - "**/*"
---

When using recalled coding-agent history:
- Treat memory as a hint, not proof.
- Summarize the recalled fix or decision before editing code.
- Check the current file, tests, and dependency versions before applying an old answer.
- Do not paste secrets, tokens, private keys, or raw logs into commits or PR notes.

That rule is boring in the best way. It turns memory into reviewable evidence instead of folklore.

Keep the memory inspectable and boring

The Hacker News discussion around deja-vu quickly found the right pressure point: local memory is attractive, but it becomes much more valuable when humans can inspect and edit it. The project currently leans deterministic and text-based, with secret redaction at index time for API keys, JWTs, and private keys.

That tradeoff is worth taking seriously. Semantic search can find fuzzy matches across messy phrasing, but it also introduces embeddings, model choice, refresh behavior, and ranking surprises. Plain text search is less magical, but it is easier to reason about when an agent is about to touch production code.

For a small repo, I would rather start with inspectable recall than clever recall. Search for the exact failure first: connection pool exhausted, JWT audience mismatch, vite env undefined, migration lock timeout. If the old answer is still correct, great. If it is stale, you have learned something useful about where memory should stop.

This connects neatly to the related training topic: the hard part of agentic coding is not only getting code written, but keeping the agent's inputs reviewable enough that a human can trust the diff.

Compare memory, not just code output

When people ask, “how do different ai code generation tools compare for enterprise software teams?”, the usual answer jumps to model quality, IDE fit, or security posture. deja-vu suggests another axis: whether the workflow preserves solved problems in a form that future agents can use.

Here is the honest comparison for this release-shaped idea.

Verdict: deja-vu wins when local, inspectable agent memory matters more than polished hosted search. Manual log search wins when you only need one old answer and do not want another tool in the loop. A fresh agent session wins when the old context is likely misleading or the task is unrelated to previous work.

If you are also comparing workbench-style visibility for coding agents, Juggler Makes Coding Agents Visible is a useful companion read. deja-vu is about memory; Juggler is about watching and steering agent work.

Try it safely on one small repo

Start with one repository that has enough history to matter but low blast radius. A good candidate is an internal service with recurring test failures, old migration notes, or repeated dependency upgrade pain. Do not begin with a repo full of secrets or production incident transcripts.

Use the project's own commands as the spine of the experiment:

# Search old agent sessions for a recurring failure
deja "connection pool exhausted"

# Inspect the shape of indexed work
deja stats

# Share a sanitized session digest with a colleague
deja share <session>

# Move memory between machines, append-only and idempotent
deja sync export
ndeja sync import

Before letting recall influence edits, add a tiny Cursor review checklist to the repo. This keeps the workflow useful for developer productivity without turning memory into an invisible authority.

A simple Cursor review checklist can live in AGENTS.md or a repo rule:

## Recalled memory boundary

Agents may use deja-vu recall for debugging context.
Before editing code, include:
- the recalled problem in one sentence
- why it still applies to the current files
- which test or command will verify the change

Do not treat recalled sessions as current documentation.

The trap is measuring success by whether the agent sounds more confident. Measure whether it avoids re-debugging a known issue and still produces a small, reviewable diff.

Common questions

• Is deja-vu a replacement for Cursor rules or AGENTS.md?

  No. deja-vu is memory; Cursor rules and AGENTS.md are instructions. Memory can tell the agent what happened before, while rules tell it how to behave now. Keep durable repo constraints in rules, and use recalled sessions as evidence the agent must summarize before editing.

• Does deja-vu use semantic search?

  Not as described in the project README. The current pitch emphasizes deterministic text search, MCP recall, auto-context, redaction, stats, sharing, and sync. That keeps the system easier to inspect, but it also means fuzzy “same idea, different words” recall may be weaker than an embedding-based system.

• How do different ai code generation tools compare for enterprise software teams?

  They compare on more than code quality. For this story, the important axis is memory: Claude Code, Codex, and opencode write local session logs that deja-vu can index and recall. A tool that writes great code but loses solved problems may still cost time on repeated debugging.

• Is local memory safer than hosted memory?

  Local memory is simpler to reason about, but it is not automatically safe. deja-vu redacts common secret shapes at index time, including API keys, JWTs, and private keys per its README. You should still inspect what gets shared, synced, and pasted into reviews.

• Where does MCP fit in this workflow?

  MCP is the bridge between the agent and the memory index. With deja-vu, the recall tool lets an agent retrieve relevant previous sessions instead of relying on a human to paste old notes. The caveat is context quality: recalled memory should be summarized and checked against current code.

Best ways to use this research

• Best for: Engineers already using coding agents enough that their local logs contain real debugging history, not just toy prompts.
• Best first artifact: Add a small AGENTS.md memory boundary that requires the agent to summarize recalled context before editing code.
• Best comparison angle: Compare AI code generation tools by retained work, recall quality, redaction, and reviewability, not only by benchmark scores or autocomplete feel.
• Best caution: Keep the first experiment deterministic and inspectable. Add semantic search later only if exact search misses too much useful history.

Further reading

• deja-vu — source
• Cursor — Agent
• OpenAI Developers — Codex quickstart
• Model Context Protocol — specification

Try the smallest useful memory test

Pick one recurring bug, search your old sessions for it, and ask the agent to explain the recalled fix before it edits anything. If the explanation is useful and the diff stays small, memory earned its place.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.