Can Claude Code see what I did in Codex or Cursor?

Not by itself — each harness reads only its own history. A shared index over all of their transcripts makes the work of one reachable from any of the others.

How do I move a session from one agent to another?

Package what the session established — the problem, the conclusions, where it stopped — as plain text the next agent starts from. deja handoff --to does that from the indexed transcript.

Do I have to re-explain the project every time I switch tools?

Only if the new tool starts empty. With recall over the shared history it opens knowing what the project has already decided, whichever agent decided it.

Switching agents without re-explaining the project

your history is not per-tool, even though every tool's memory is

Most people use more than one. Claude Code for the long refactor, Codex for a quick fix, Cursor because the file is already open, opencode or Zed because that is where the terminal is. Each keeps its own history, and none of them can read another's — so switching tools means explaining the project again.

Two different problems

They get talked about as one thing, and they are not.

Recall: the work already happened somewhere

You are in Codex now, and the answer is in a Claude Code session from July. Nothing needs to be transferred — it needs to be findable. One index over every harness's transcripts makes the question answerable from whichever agent you happen to be in:

$ deja "connection pool exhausted"
[claude] api   · Jul 8 · 8f31c0a9 — 2 matches
  login started failing after refresh token rotation; jwt kid mismatch in tests
  fixed by reloading jwks cache after rotateKey and adding a clock-skew test
[codex]  web   · Jul 1 · b77d91e2 — 1 match
  refresh token cookie needed SameSite=Lax in local callback flow

With recall wired in, the agent runs that lookup itself when a prompt matches earlier work — including work from a tool you have since stopped using.

Handoff: this session should continue over there

The other case is a live piece of work that has to move — the model hit a usage limit, or the job is better suited to a different agent. That is not a search; it is packaging what the session established so the next one starts from it:

deja handoff --to codex

It reads the session from the index and prints what the next agent needs: the problem, what has been established, and where it stopped. --exec launches the target agent with it. No protocol between the two tools, nothing to install on both ends, and it works between agents that know nothing about each other.

Why a per-tool memory does not cover it

Every harness that ships memory scopes it to itself, which is the correct choice for them and the wrong shape for you: your history is not per-tool, and the tool you were using in March is a detail of that month, not a property of the problem. On a real machine the errors that recur are usually hit under two or three different agents — deja friction prints the harness names beside each one, and the list is rarely a single tool.

What it takes

curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | sh
deja install --auto

The second command wires recall into every agent it finds on the machine and builds the index over all of their stores at once — twenty of them today, including the sessions that predate the install. Nothing is copied between tools and no history is moved: one local index, read by whichever agent is asking.

Across machines rather than tools, deja sync ssh <host> moves the index itself, append-only and with no service in the middle.

Why agents forget · When the same wall comes back · Which agent supports what