deja-vu turns coding-agent history into a local memory layer builders can actually reuse

updates

vshulcz/deja-vu turns the session logs your coding agents already write into a local memory layer with fast search, MCP recall, auto-context injection, and redaction-first sharing instead of another cloud knowledge silo.

GitHub README capture for vshulcz/deja-vu

Coding agents are getting better at solving real work, but they still suffer from an expensive kind of amnesia.

A team can spend days debugging auth flows, cleaning up migrations, or figuring out why one harness succeeds where another fails. Then the useful part of that work gets buried inside local session logs that are technically on disk but practically lost. Most memory products attack that problem by asking teams to adopt yet another hosted knowledge layer.

deja-vu takes a more pragmatic route: it starts from the transcripts your tools already produce and turns them into something your next agent session can actually reuse.

That framing is what makes the repo notable. Instead of inventing a new chat surface, new datastore, or new collaboration ritual, it treats memory as an infrastructure upgrade for the agent stack developers already have.

It treats session logs like a real product asset

The most compelling part of deja-vu is not just that it can search old transcripts. It is that the project assumes those transcripts already contain high-value engineering decisions, bug hunts, and working fixes that should be queryable like any other asset.

The README promises search over multi-gigabyte local histories in milliseconds, plus a compact ctx digest mode that can be piped back into a prompt. That matters because the bottleneck is not only finding an old answer. It is recovering just enough verified context to keep the next run from wasting tokens and attention re-deriving the same fix.

For builders, that is a sharper product thesis than generic "AI memory." It says the memory source of truth is the work you have already done, not another place you now need to maintain by hand.

The integration story is stronger than the feature list

A lot of agent tooling looks useful in isolation and then dies on setup friction. deja-vu feels more serious because the integration path is baked into the product.

The repo supports Claude Code, Codex, opencode, Cursor, Gemini CLI, Grok Build, Qwen Code, and more, then wires recall through MCP and optional session-start hooks. In practice that means the memory layer is not just a search CLI you promise yourself you will remember to use later. It can become part of how the agent starts work.

That is an important distinction. The best workflow automation often wins not by adding more capability, but by landing in the one place where humans reliably forget to be disciplined. Session-start auto-recall is exactly that kind of move.

I also like that the project stays grounded in local-first constraints. One zero-dependency binary, incremental indexing, retroactive search across months of old logs, and optional embedding reranking only if you want it. That gives the repo a very different feel from systems that assume a remote vector database is the starting point.

The privacy model makes the concept more credible

Memory tools become much more interesting once you imagine turning them loose on real engineering logs, because those logs are full of credentials, internal URLs, and unfinished reasoning.

This is where deja-vu earns trust. The project foregrounds redaction at index time, supports forgetting and tombstones, and makes sharing or sync flows reapply the redaction boundary on the way out. That is not glamorous, but it is the difference between a clever demo and something a serious developer could actually keep around.

The share and sync features are also product-minded in a way many open-source agent tools are not. The project is not only asking, "How do I remember this later on the same machine?" It is also asking how memory moves between machines and teammates without turning into a privacy leak or a heavyweight service.

The file-level blame angle is quietly powerful

One feature I think deserves more attention is deja blame <path>.

That command reframes agent memory from a general search tool into something much closer to engineering traceability. If a file was changed during three messy sessions and nobody remembers why a workaround exists, being able to ask which sessions discussed that path is a strong bridge between conversational work and code archaeology.

That is the sort of capability that can make agent-heavy workflows feel less opaque over time. Teams do not just need agents to do work faster. They need the resulting trail of decisions to stay inspectable.

Where builders should stay realistic

deja-vu is promising, but it is still an early-stage infrastructure layer.

Its value depends heavily on the quality of the underlying session logs and the discipline of the harnesses it supports. Auto-recall also has to stay selective, because too much injected context quickly becomes a different kind of noise. The project is clearly aware of that tradeoff, which is why it documents safe versus aggressive recall modes and keeps the injected memory budget bounded.

There is also a social question underneath the tooling: once teams can search and reuse more past agent work, they will need norms for what counts as a durable decision versus a one-off experiment. Tools like remember, share, and sync help, but they do not replace judgment.

Why this repo stands out

deja-vu stands out because it does not pitch memory as a magical AI layer.

It pitches memory as a missing product primitive for coding agents: fast local retrieval, sane privacy defaults, integration into the harnesses developers already use, and enough packaging discipline that the whole thing can live as a boring part of the workflow. That is exactly the kind of open-source idea worth watching, because it attacks one of the most persistent weaknesses in agent-based development without asking teams to start over.

Repo

GitHub: https://github.com/vshulcz/deja-vu