deja-vu Shares Agent Memory Over SSH

deja-vu is vshulcz’s open-source Go binary for turning coding-agent session logs into local memory. It deals with a plain failure mode: Claude Code, Anthropic’s coding agent, OpenAI Codex, and opencode can debug the same issue twice because old answers sit in separate local histories. The takeaway is simple: shared, searchable memory may matter as much as the model when you compare ai code generation workflows. deja-vu is not a new agent; it is an index, recall tool, redactor, sharing command, and sync layer over logs your agents already write.

Read the release as a memory layer, not another agent

deja-vu’s pitch is wonderfully direct: your agents already solved this, and deja finds it. The project reads local conversation files from Claude Code, Codex, and opencode, then makes them searchable from a single zero-dependency binary.

A coding-agent memory layer is a local index that lets future agent sessions reuse past debugging notes, decisions, commands, and fixes. In deja-vu’s case, that memory comes from the session logs already sitting on disk, not from a hosted knowledge service.

That detail is why developers cared. The interesting part is not that it stores memories. The interesting part is that it starts retroactively, over old logs, without asking you to change agents first.

As of July 2026, the GitHub repository showed 222 stars, was mainly written in Go, used an MIT license, and had been pushed on July 14. Those are small-project numbers, not enterprise-platform numbers. They are also the right size for a developer tool that is still testing whether the workflow is real.

The README claims search in roughly 7–9 ms over gigabytes of logs, plus an MCP recall tool, install --auto for SessionStart auto-context, secret redaction at index time, stats, sanitized sharing, and append-only import/export sync. The release story is SSH-friendly because export/import can move the memory cache between machines without requiring a central service.

The trap is treating this like magic long-term memory. It is closer to ripgrep for agent sessions, with just enough MCP surface for an agent to ask, “Have we seen this before?” That is less glamorous. It is also much easier to inspect.

Compare the memory boundary, not just the agent

This is also a better way to ask “how do different ai code generation tools compare for enterprise software teams?” without collapsing the answer into model benchmarks. For a real codebase, the comparison often turns on boring boundaries: where context lives, whether a human can inspect it, and whether it survives switching tools.

Here is the useful comparison hiding inside the deja-vu release.

Verdict: deja-vu wins when you want cross-harness local memory that a developer can inspect, search, and move. Raw logs win when you only need one forensic lookup and do not want another index. Product-native context wins when you stay inside one agent and value convenience more than portability.

That last line is the honest enterprise comparison. Claude Code, Codex, Claude, Anysphere’s AI code editor, and other coding agents compete on much more than output quality. They compete on how evidence, memory, permissions, and review fit the way a repository actually changes.

For more on this corner of agentic coding, see deja-vu Syncs Coding Agent Memory and the broader related training topic.

Notice what is clever, and what is still rough

The clever part is the source of truth. deja-vu does not ask developers to curate a new knowledge base. It mines the awkward pile of old agent sessions that already contains real fixes, failed commands, and design decisions.

That makes it useful for bugs with a smell. Think of a Rails service where connection pool exhausted appeared three weeks ago during a Sidekiq deploy. A fresh agent session may propose generic pool-size advice. A deja-backed recall can surface the older session where someone found the actual culprit: a forgotten transaction around a batch import.

The second clever part is redaction at index time. Session logs can contain secrets because agents see terminal output, config files, stack traces, and pasted debugging notes. A memory tool that ignores that fact is not ready for real repositories.

The rough part is the search model. A Hacker News objection got to the heart of it: local memory is more valuable when it is inspectable and manually editable, but deterministic text search can miss semantic matches. If the old session said “Postgres clients leaked under worker retries” and you search for “connection pool exhausted,” a pure text index may or may not find the thing you meant.

That tradeoff is not a flaw by itself. Deterministic search is explainable. Semantic search is forgiving. The uncomfortable middle is pretending you get both without new storage, new embeddings, and new trust questions.

Try it on one small repo first

Do not start with your most sensitive repository. Start with a small service where the team has already used Claude Code or Codex enough to produce useful logs.

A good first test is a recurring local-dev bug. Pick something you remember fixing, but not the exact command. Then ask deja-vu to find it before you open a fresh agent session.

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

# Check what deja-vu indexed before trusting it
deja stats

# Create a sanitized handoff from one useful session
deja share <session-id>

# Move memory between machines through your normal SSH copy path
deja sync export > deja-memory.jsonl
# scp deja-memory.jsonl devbox:/tmp/
# on the other machine:
deja sync import < /tmp/deja-memory.jsonl

For Claude Code users, the interesting boundary is deja install --auto. The README says it adds a SessionStart hook so relevant memory lands in context before you ask. That can be lovely, but it should be boringly visible.

A small hook boundary note is enough:

Claude Code hook boundary for deja-vu

- Event: SessionStart only.
- Allowed action: read from the local deja-vu index and add relevant prior-session context.
- Not allowed: run network sync, mutate source files, or import memory automatically.
- Human check: run `deja stats` and one manual `deja "<known bug>"` query before enabling auto-context.

The trap is enabling auto-recall before you know what the index contains. Old sessions include wrong turns. They include “fixed” ideas that were later reverted. Memory should enter the context as evidence, not as law.

Copy this fit/not-fit note

Use this as the small experiment receipt. It is intentionally lightweight. You want to learn whether shared memory helps before you bless it as part of the everyday path.

A useful pass looks like this: one known bug found, one stale or wrong memory identified, one sanitized share tested, and one import/export round trip completed. If you cannot inspect those four things, you are testing vibes instead of behavior.

Common questions

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

  They compare best by workflow boundary, not only by model output. For this story, the boundary is memory: Claude Code, Codex, and opencode can all produce local histories that deja-vu indexes, while other tools may keep useful context inside their own product surface.

• Does deja-vu use semantic search?

  The public README emphasizes fast text search, MCP recall, redaction, stats, sharing, and sync; it does not present semantic search as the core feature. That is a real tradeoff: deterministic search is inspectable, but it may miss older sessions that solved the same idea with different words.

• Is the sync really over SSH?

  deja-vu exposes deja sync export/import, so the SSH part is the transport pattern rather than a special hosted sync service. You can export on one machine, copy the append-only data through SSH or scp, and import it on another without running a central memory server.

• What should Claude Code users check first?

  Check the SessionStart hook boundary before enabling auto-context. The safe first pass is manual: run one known search, inspect deja stats, create one sanitized deja share handoff, and only then consider install --auto for a repo with low secret risk.

• Can this replace repository memory like CLAUDE.md?

  No, it should not replace concise repository memory. A file like CLAUDE.md is for durable rules and conventions, while deja-vu is for remembered episodes: old debugging sessions, prior fixes, and decisions that may or may not still be true.

Best ways to use this research

• Best for: comparing coding agents by context portability, especially when developers already move between Claude Code, Codex, and opencode.
• Best first artifact: a one-repo memory receipt showing one successful search, one inspected stale result, one sanitized share, and one sync export/import.
• Best comparison angle: ask where memory lives, who can inspect it, how secrets are handled, and whether it survives a tool switch.
• Best caution: treat recalled sessions as clues. Old agent output can be useful and still be wrong.

Further reading

• deja-vu — source
• Claude Code — hooks
• Claude — Agent
• OpenAI Developers — Codex quickstart

Next step

Try deja-vu against one remembered bug in one small repo, then inspect the result before wiring it into any automatic context path. If it finds the old fix and the redaction looks sane, you have a real signal worth testing further.

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.