- by x32x01 ||
Imagine that Claude Code solves a difficult bug in your project today. A few weeks later, Codex or another coding agent runs into the same problem.
Normally, the new agent may have no idea that the problem was already solved.
Deja-vu takes a different approach: it turns the session history already stored by your coding agents into a searchable, shared memory layer.
Instead of keeping useful experience locked inside one AI coding agent, Deja-vu can make that history available across different agents through a local index and MCP integration.
Your coding agents already save session transcripts locally. Deja-vu reads those existing histories, builds a local search index, and lets agents retrieve relevant sessions when they need them.
This means the memory does not have to start from zero when you install the tool. Deja-vu is designed to index existing session history, including sessions created before the installation.
Three weeks later, you ask Codex to investigate a similar issue.
Without access to the previous session, Codex may investigate the problem from scratch.
With Deja-vu, the agent can search its shared history and retrieve the earlier session:
Previous session: The same connection pool problem was investigated and fixed three weeks ago.
The agent can then use that previous experience as a starting point instead of repeating the entire investigation.
That is the core idea behind Deja-vu: your previous agent sessions become searchable knowledge instead of forgotten transcripts.
Context is what the agent currently knows inside its active session. It includes things such as:
Memory is information from previous sessions that can be retrieved later.
For example:
Deja-vu is focused on making that historical information searchable and available to different coding agents. (Vshulcz)
A shared memory layer can help with problems such as:
That can be especially useful in large projects where the same technical problem may appear months later.
Deja-vu takes a different approach.
It works from the session history that coding agents have already written to disk. According to the project's documentation, it uses a local index and does not require an LLM, embeddings, or an API key for its core retrieval system.
The project is also designed as a local, zero-dependency binary, with MCP support for connecting the memory layer to coding agents.
This gives the architecture a simple flow:
Agent sessions → Local history → Deja-vu index → Search/Recall → AI coding agent
You can then connect Deja-vu to supported coding agents and enable automatic recall:
The project's documentation says this installs the integration, enables session-start recall where supported, and builds the initial index.
Other installation options include Homebrew, Go, npm, and platform-specific packages.
For example:
Instead of searching only the current conversation, Deja-vu can look through indexed sessions and return relevant previous work.
The project reports millisecond-scale search over gigabytes of session history, although actual performance depends on the size and contents of the local history.
You can also ask an integrated coding agent to recall previous work through its MCP integration.
With automatic recall enabled, Deja-vu can provide relevant previous memories when a new session starts or around relevant agent actions, depending on the coding agent being used.
That changes the workflow from:
Developer → Agent → Search memory manually
to:
Developer → Agent → Relevant previous experience is available automatically
The goal is not to make the agent remember everything. The goal is to make useful previous experiences available at the right time.
The project supports integrations across a growing list of coding-agent environments, including Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Copilot and others.
That makes this possible:
Claude Code solves a problem → Deja-vu indexes the session → Codex later recalls the solution.
The agent changes, but the development history remains available.
The project also documents synchronization between machines using SSH, allowing memory records to be transferred between systems without putting a cloud service in the middle.
However, local does not automatically mean risk-free.
Your original agent session files may already contain sensitive information, so you should still understand what your coding agents store locally and review Deja-vu's privacy and redaction behavior before using it with sensitive projects.
The project states that credentials are stripped during indexing and that secrets remain in the original agent files rather than entering the Deja-vu index or sync exports.
Saving every conversation is not the same as having useful memory.
An effective memory system needs to answer two questions:
What should be remembered?
and
When should it be retrieved?
For example, remembering that a developer once tested a particular approach can be useful.
But retrieving that information every time the agent opens the project could simply add noise.
The useful memory is the information that is relevant to the current task.
That is why retrieval quality matters just as much as storage.
Coding agents do the work.
Deja-vu makes previous work searchable.
MCP provides a way for compatible agents to interact with that memory.
It is the idea of treating the history already produced by AI coding agents as a reusable development resource.
A solution discovered by one agent does not necessarily have to disappear when that session ends.
Instead, it can become part of a shared memory layer that other agents can search and reuse later.
For developers who regularly switch between Claude Code, Codex, Cursor, and other AI coding tools, this approach could make long-term project history much more useful.
The project is open source and available on GitHub
Normally, the new agent may have no idea that the problem was already solved.
Deja-vu takes a different approach: it turns the session history already stored by your coding agents into a searchable, shared memory layer.
Instead of keeping useful experience locked inside one AI coding agent, Deja-vu can make that history available across different agents through a local index and MCP integration.
How Deja-vu Works
The basic idea is simple: Code:
Claude Code ─┐
Codex ──────┤
Cursor ─────┼──> Shared Memory
Other Agents ┘This means the memory does not have to start from zero when you install the tool. Deja-vu is designed to index existing session history, including sessions created before the installation.
A simple example
Suppose Claude Code discovers why a connection pool keeps failing and fixes the problem.Three weeks later, you ask Codex to investigate a similar issue.
Without access to the previous session, Codex may investigate the problem from scratch.
With Deja-vu, the agent can search its shared history and retrieve the earlier session:
Previous session: The same connection pool problem was investigated and fixed three weeks ago.
The agent can then use that previous experience as a starting point instead of repeating the entire investigation.
That is the core idea behind Deja-vu: your previous agent sessions become searchable knowledge instead of forgotten transcripts.
Context Is Not the Same as Memory
One of the most important concepts here is the difference between context and memory.Context is what the agent currently knows inside its active session. It includes things such as:
- The files it has opened.
- The conversation you are having now.
- Commands it has recently run.
- Errors and results from the current task.
Memory is information from previous sessions that can be retrieved later.
For example:
Context → "Here is the bug we are debugging right now."Memory → "We had a similar bug three weeks ago, and this was the solution."Deja-vu is focused on making that historical information searchable and available to different coding agents. (Vshulcz)
Why Shared Agent Memory Matters
AI coding agents are becoming increasingly capable, but they can still waste time repeating investigations that have already happened.A shared memory layer can help with problems such as:
- Finding how a previous bug was fixed.
- Remembering approaches that were already tried.
- Finding previous design decisions.
- Reusing solutions from another coding agent.
- Continuing work across different AI coding tools.
- Searching months of previous development sessions.
That can be especially useful in large projects where the same technical problem may appear months later.
What Makes Deja-vu Different?
Many AI memory systems require an agent to explicitly save information into a memory database.Deja-vu takes a different approach.
It works from the session history that coding agents have already written to disk. According to the project's documentation, it uses a local index and does not require an LLM, embeddings, or an API key for its core retrieval system.
The project is also designed as a local, zero-dependency binary, with MCP support for connecting the memory layer to coding agents.
This gives the architecture a simple flow:
Agent sessions → Local history → Deja-vu index → Search/Recall → AI coding agent
Installing Deja-vu
The project provides several installation methods. One option is the official installation script: Bash:
curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | shYou can then connect Deja-vu to supported coding agents and enable automatic recall:
Bash:
deja install --autoOther installation options include Homebrew, Go, npm, and platform-specific packages.
Searching Previous Sessions
You can search your history directly from the command line.For example:
Bash:
deja "connection pool exhausted"The project reports millisecond-scale search over gigabytes of session history, although actual performance depends on the size and contents of the local history.
You can also ask an integrated coding agent to recall previous work through its MCP integration.
Automatic Memory Recall
Manually searching for old sessions is useful, but automatic recall is more interesting.With automatic recall enabled, Deja-vu can provide relevant previous memories when a new session starts or around relevant agent actions, depending on the coding agent being used.
That changes the workflow from:
Developer → Agent → Search memory manually
to:
Developer → Agent → Relevant previous experience is available automatically
The goal is not to make the agent remember everything. The goal is to make useful previous experiences available at the right time.
Memory Across Different Coding Agents
One of the most interesting parts of Deja-vu is that the memory layer is not limited to a single coding agent.The project supports integrations across a growing list of coding-agent environments, including Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Copilot and others.
That makes this possible:
Claude Code solves a problem → Deja-vu indexes the session → Codex later recalls the solution.
The agent changes, but the development history remains available.
Is the Memory Stored in the Cloud?
Deja-vu is designed around local session history and local indexing rather than requiring a hosted memory service for its core search functionality.The project also documents synchronization between machines using SSH, allowing memory records to be transferred between systems without putting a cloud service in the middle.
However, local does not automatically mean risk-free.
Your original agent session files may already contain sensitive information, so you should still understand what your coding agents store locally and review Deja-vu's privacy and redaction behavior before using it with sensitive projects.
The project states that credentials are stripped during indexing and that secrets remain in the original agent files rather than entering the Deja-vu index or sync exports.
The Real Challenge: What Should an Agent Remember?
This is where AI memory becomes more interesting.Saving every conversation is not the same as having useful memory.
An effective memory system needs to answer two questions:
What should be remembered?
and
When should it be retrieved?
For example, remembering that a developer once tested a particular approach can be useful.
But retrieving that information every time the agent opens the project could simply add noise.
The useful memory is the information that is relevant to the current task.
That is why retrieval quality matters just as much as storage.
Deja-vu in the AI Coding Workflow
A practical workflow could look like this:- An AI coding agent investigates a problem.
- The agent finds and implements a solution.
- The session is stored locally by the coding environment.
- Deja-vu indexes the session.
- A similar problem appears later.
- Another coding agent searches the shared history.
- The previous investigation becomes available as context.
- The new agent continues from that information instead of starting completely from scratch.
Coding agents do the work.
Deja-vu makes previous work searchable.
MCP provides a way for compatible agents to interact with that memory.
Final Thoughts
The interesting idea behind Deja-vu is not simply "give an AI a memory."It is the idea of treating the history already produced by AI coding agents as a reusable development resource.
A solution discovered by one agent does not necessarily have to disappear when that session ends.
Instead, it can become part of a shared memory layer that other agents can search and reuse later.
For developers who regularly switch between Claude Code, Codex, Cursor, and other AI coding tools, this approach could make long-term project history much more useful.
The project is open source and available on GitHub