deja-vu Adds Local Memory Over SSH

deja-vu is vshulcz’s open-source Go binary for turning local coding-agent session logs into searchable memory. It deals with a boring, expensive problem: Claude Code, Codex, and opencode can solve something once, then forget it in the next session. The takeaway is simple: for serious AI code generation work, the memory layer is starting to matter as much as the agent prompt.

Put another way, how do different ai code generation tools compare for enterprise software teams? One useful answer is: compare what they can remember, inspect, redact, and reuse across sessions, not only what they generate in a fresh chat.

As of July 2026, the deja-vu repository showed 223 GitHub stars, an MIT license, mostly Go code, and a last push on July 14. That is still small-project territory. But the idea is sharp because it leans on files developers already have.

Read old agent sessions before re-debugging

The pitch is wonderfully plain: your agents already solved this, and deja-vu finds it.

Claude Code, Anthropic’s coding agent, Codex, OpenAI’s coding agent, and opencode, SST’s open-source terminal coding agent, all write conversation history to local files. deja-vu indexes those histories and lets you search them with commands like deja 'connection pool exhausted'.

The clever part is that it is retroactive. You do not start collecting memory after installing a hosted service. You point a local binary at session logs that may already contain months of failed migrations, flaky tests, design decisions, and that one Redis bug nobody wants to debug again.

The README claims 7–9 ms search over gigabytes of logs. Treat that as a project claim, not a benchmark for your repo. Still, the design choice is important: deterministic text search is inspectable, cheap, and easy to reason about.

The trap is assuming old chat logs are clean knowledge. They are not. They contain guesses, dead ends, secrets, half-finished plans, and stale architecture. deja-vu helps find the prior work; it does not decide whether that work is still true.

Treat MCP recall as a boundary

deja-vu also exposes an MCP recall tool so an agent can ask for relevant prior sessions. MCP is a protocol that lets coding agents call external tools and data sources through a defined interface.

That boundary matters. If Codex can query old sessions through MCP, the agent can say something closer to “we fixed this three weeks ago” instead of re-running the same investigation from zero. That is useful when the bug spans harnesses: maybe Claude Code found the root cause, but today you are driving the change through Codex.

The project also supports install --auto, which adds a SessionStart hook so relevant memory lands in context before you ask. That is convenient, but it deserves a small caution label. Automatic context can be wrong, noisy, or too persuasive.

A good Codex boundary note is short and explicit:

# AGENTS.md

## Agent memory
- You may use deja-vu MCP recall for prior local sessions.
- Treat recalled sessions as hints, not source of truth.
- Verify recalled fixes against current tests before editing code.
- Do not paste secrets, tokens, or private customer data into summaries.

That little note keeps recall in the same category as grep, logs, and commit history. Helpful. Not authoritative.

Compare agents by the memory they can reuse

Most AI coding comparisons still focus on model quality, editor surface, or how fast a tool produces a patch. deja-vu points at a different comparison: what happens after the first successful fix?

Here is the honest comparison for this project’s lane.

Verdict: Claude Code wins when its past sessions contain the richest debugging trail, Codex wins when you want the recall loop close to a CLI-driven patch-and-test workflow, and opencode wins when you want an open-source terminal agent in the mix. deja-vu’s bet is that the best memory is not tied to one harness.

That is why this project sits naturally inside the related training topic: not because memory solves review, but because remembered context changes what reviewers need to check.

Try it safely on one small repo

Do not start with the largest monorepo or the most sensitive customer system. Start with one repo where the history is useful but the blast radius is low: a CLI package, an internal service, or a test-heavy library.

The practical question is not “should every agent remember everything?” It is “can remembered sessions save one repeat investigation without smuggling bad context into the patch?”

Use this small fit/not-fit table before you wire it into a daily Codex loop.

A tiny experiment can be enough. Pick one old bug, run deja stats to see what logs are available, search for the error, and ask Codex to propose a fix only after it has read the current failing test.

Then use a normal verification loop:

deja stats
deja 'connection pool exhausted'
# open the relevant recalled session
git status
# run the repo's focused test command
# review the diff before widening the test run

The SSH part is attractive because it keeps the workflow local-first. Export, move, import, inspect. If you want a deeper note on the same project’s sharing angle, see deja-vu Shares Agent Memory Over SSH.

Notice what is still rough

deja-vu is intentionally not a big memory platform. The README emphasizes one zero-dependency binary, no models to download, and no services to run.

That restraint is a strength. It also means you should not expect semantic memory, embeddings, permissions dashboards, or policy workflows out of the box. A developer in the discussion around the release raised the right question: memory becomes more valuable when it is easy to inspect and edit manually.

Text search is transparent. Semantic search is forgiving. The first helps you trust what matched; the second helps when nobody remembers the exact phrase. deja-vu appears to choose the transparent path first, which is the right default for local coding-agent memory.

Secret handling is another place to be careful. The project says API keys, JWTs, and private keys are stripped at index time, and deja share produces a sanitized digest. That is useful protection, not permission to stop reviewing what leaves your machine.

Common questions

• Is deja-vu a replacement for better prompts?

  No. deja-vu is a memory layer over past local sessions, not a prompt-writing system. Its value is strongest when the answer already exists in previous agent work, such as a debug trail, command output, or design note that would otherwise be buried in gigabytes of logs.

• Does this make ai code generation safer?

  It can make AI code generation more grounded, but it does not make generated code safe by itself. The useful artifact is the recalled session plus a current verification loop: inspect the memory, compare it to today’s code, run focused tests, and review the diff before trusting the patch.

• Should I enable auto-recall immediately?

  Not immediately. Try manual search and MCP recall first, then enable install --auto only if the recalled context is consistently relevant. SessionStart hooks are powerful because they shape the agent’s first assumptions, so stale or noisy memory can quietly steer a session in the wrong direction.

• Is deterministic text search enough, or does agent memory need semantic search?

  Deterministic text search is enough for exact errors, filenames, stack traces, and known incidents. It is weaker when the same problem was described with different words. That tradeoff is also why local, inspectable memory is appealing: you can see exactly what matched before giving it to an agent.

• How should Codex users try it without polluting a repo?

  Keep the first test read-only. Use deja stats, run one search against an old issue, and paste only the relevant recalled facts into a Codex task with a focused test command. Add an AGENTS.md note that recalled sessions are hints, not project rules.

Best ways to use this research

• Best for: developers comparing coding agents who want to include memory, recall, redaction, and local inspectability in the comparison.
• Best first artifact: a small AGENTS.md boundary note that tells Codex how to treat deja-vu recall during a patch.
• Best comparison angle: ask whether a tool can reuse yesterday’s debugging across Claude Code, Codex, and opencode, not only whether it can generate today’s code.
• Best caution: test redaction and sharing with non-sensitive sessions before using digests in real handoffs.

Further reading

• deja-vu — source
• OpenAI Developers — Codex quickstart
• Codex, Anysphere — Agent overview
• Model Context Protocol — specification

Next step

Try deja-vu on one repo with one remembered bug, then decide from the evidence. If the recalled session saves real time and survives current tests, it has earned a place in your Codex workflow.

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.