[FEATURE] Shared memory / persistent identity across Claude sessions

I have the same setup and the same problem: Claude Code on a laptop, another on a box I reach over remote desktop, and claude.ai for documents. Three sessions on one project, none of them aware of the others.

What worked for me was moving the memory off the machine and into an MCP server that all the sessions connect to. When a session finishes something worth keeping, it writes it there with who wrote it and when, and the next session on any machine reads it back when it starts. Your Solaris 8 emulator afternoon would be one entry, and the laptop would pick it up without you retyping any of it.

I built it, so weigh that accordingly. It is called One Brain, it is free while in beta, and it is at onebrain.prophet.lat/en. It is small today. The design came out of my own work with companies that are not technical at all, which is why every entry carries its author and date: a week later the question is usually who decided this and why, not where it is stored.

Happy to just walk you through how it is wired if you would rather build your own. The storage was never the hard part.

Thank you for your suggestion batafilippini. However this approach seems to be more applicable to sequential workflows i.e. do one task on a machine, move on to the next, and so on. I’m typically working on multiple systems simultaneously. Correct me if I misunderstood your solution. My solution is to have other Claude generate documents highlighting our progress that I feed back to my main Claude. That way it’s aware of what we are doing elsewhere. I just wish it was naturally aware.

Regards,
Marc

From: batafilippini @.*>
Sent: Sunday, August 23, 2026 5:55 PM
To: anthropics/claude-code @.*>
Cc: Lariviere, Marc-Andre (Plasma-Therm LLC) @.>; Author @.>
Subject: Re: [anthropics/claude-code] [FEATURE] Shared memory / persistent identity across Claude sessions (Issue #87834)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[Image removed by sender.]batafilippini left a comment (anthropics/claude-code#87834)<https://github.com/anthropics/claude-code/issues/87834#issuecomment-5389504290>

I have the same setup and the same problem: Claude Code on a laptop, another on a box I reach over remote desktop, and claude.ai for documents. Three sessions on one project, none of them aware of the others.

What worked for me was moving the memory off the machine and into an MCP server that all the sessions connect to. When a session finishes something worth keeping, it writes it there with who wrote it and when, and the next session on any machine reads it back when it starts. Your Solaris 8 emulator afternoon would be one entry, and the laptop would pick it up without you retyping any of it.

I built it, so weigh that accordingly. It is called One Brain, it is free while in beta, and it is at onebrain.prophet.lat/en. It is small today. The design came out of my own work with companies that are not technical at all, which is why every entry carries its author and date: a week later the question is usually who decided this and why, not where it is stored.

Happy to just walk you through how it is wired if you would rather build your own. The storage was never the hard part.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/87834?email_source=notifications&email_token=CAPJG3MJJX3LE533DHYHOD35LOG5LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYHE2TANBSHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5389504290>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CAPJG3KSUHHUIAEH2KUS4UT5LOG5LAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TKMJYHEYTKMZUGI2KC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CAPJG3LEOJXTTZPUNGG6KYT5LOG5LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYHE2TANBSHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/CAPJG3JAOGF3CKKTJI46EKD5LOG5LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYHE2TANBSHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today!
You are receiving this because you authored the thread.Message ID: @.***>

You read it as sequential, and that is on me for not being clearer. It is not turn based. Every session writes into the same store the moment it closes something, and reads from it when it starts. Three machines running simultaneously all write and read at the same time, with no handoff between them.

Your current fix is the interesting part, because it is the same shape as what I ended up building, except you are doing the transport by hand. Other Claudes produce the progress documents, and then you carry them over to the main one. That carrying step is the part that disappears: the write lands in a shared place instead of in a file you move.

"I just wish it was naturally aware" is exactly what I was after. To be honest it is not truly natural, something still has to do the writing. The difference is that the writing happens inside the session at the moment a thing closes, so it is not you moving it afterwards.

Happy to show you how it behaves with three machines going at once, if that is useful. And if you would rather build your own, the pattern is simple and I am glad to describe how it is wired.

Link again in case it is easier than scrolling up: https://onebrain.prophet.lat/i/r6

The multi-writer thread here is the part that decides whether shared
memory works at all. We ran into the same wall with a git-backed store, and
the lesson was that sharing a directory is the easy half; the hard half is
that a read without provenance becomes a confidently wrong action. Three
things made our setup usable across machines:

1. Every entry carries a non-optional author and date line at write time, so

a reader can always ask "who wrote this, when" before acting on it.

1. Contradictions between writers are not resolved by timestamp — the newer

entry carries an explicit supersede edge naming what it replaces. "Which
entry is live" becomes data instead of a heuristic two writers can disagree
on. This is the piece that answers the concurrent-writers worry directly:
append-only writes with provenance never overwrite each other, so
simultaneous sessions are safe by construction and conflicts surface as
explicit supersede chains to review rather than silent
last-writer-wins overwrites.

1. The health check only ever claims "healthy as of this machine's last sync",

never "healthy". Cross-machine staleness then degrades into a readable diff
at pull time instead of an invisible contradiction.

One more thing worth deciding early: what happens on read when an entry has
no supersede successor but contradicts a live entry from another writer. We
classify that as a provenance breach with its own exit code rather than as
hygiene noise, because it is exactly the case where acting on stale shared
memory looks identical to acting on fresh local memory.

Hi again!

Forgive me for having AI review your suggestion:
Bottom line
My reading is that batafilippini is advocating for a shared-memory, multi-agent architecture where memory becomes infrastructure rather than an artifact manually moved between sessions. The proposal is compelling from a usability and productivity standpoint, but the email does not provide enough detail to judge how robust the implementation would be in practice

So it seems like I would definitely benefit from your approach. Would the shared memory location be stored somewhere locally on one of my systems, or elsewhere?

Regards,
Marc

From: batafilippini @.*>
Sent: Monday, August 24, 2026 8:23 AM
To: anthropics/claude-code @.*>
Cc: Lariviere, Marc-Andre (Plasma-Therm LLC) @.>; Author @.>
Subject: Re: [anthropics/claude-code] [FEATURE] Shared memory / persistent identity across Claude sessions (Issue #87834)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[Image removed by sender.]batafilippini left a comment (anthropics/claude-code#87834)<https://github.com/anthropics/claude-code/issues/87834#issuecomment-5397388741>

You read it as sequential, and that is on me for not being clearer. It is not turn based. Every session writes into the same store the moment it closes something, and reads from it when it starts. Three machines running simultaneously all write and read at the same time, with no handoff between them.

Your current fix is the interesting part, because it is the same shape as what I ended up building, except you are doing the transport by hand. Other Claudes produce the progress documents, and then you carry them over to the main one. That carrying step is the part that disappears: the write lands in a shared place instead of in a file you move.

"I just wish it was naturally aware" is exactly what I was after. To be honest it is not truly natural, something still has to do the writing. The difference is that the writing happens inside the session at the moment a thing closes, so it is not you moving it afterwards.

Happy to show you how it behaves with three machines going at once, if that is useful. And if you would rather build your own, the pattern is simple and I am glad to describe how it is wired.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/87834?email_source=notifications&email_token=CAPJG3IKFINUN3XEZYUKOUT5LRMTVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZG4ZTQOBXGQY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5397388741>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CAPJG3MMJJQVLMC4JIJ4LQ35LRMTVAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TKMJYHEYTKMZUGI2KC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CAPJG3NTPZOIKFTLOYY4V6T5LRMTVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZG4ZTQOBXGQY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/CAPJG3N5PFAPJ6ASFTHRJDT5LRMTVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZG4ZTQOBXGQY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today!
You are receiving this because you authored the thread.Message ID: @.***>

Hi Marc,

Short answer: today it lives on our server, and your machines reach it over MCP. Any of your three Claude instances reads and writes to the same store, so nothing gets copied between sessions by hand.

If the data can't leave your network, the same server can run inside your own infrastructure. That one we set up per company, it isn't self serve yet.

On the robustness question your review raised: the part that actually breaks in practice isn't storage, it's two sessions writing at the same time. Every write is an append, never a rewrite of another session's entry, and each entry carries who wrote it and when. When something looks off you can trace it to a person and a date instead of trusting a merged file.

If it helps, I can show you with three machines running at once.

the three-machine shape is the part worth separating from the shared-memory question, because it has a different answer.

each of your claude code instances already writes every session to disk — ~/.claude/projects/<encoded-cwd>/*.jsonl, one file per session, appended as it goes. so the rocky box does have a full record of the two hours on the solaris emulator. what is missing is not the record, it is that nothing on the laptop can read it.

that framing matters because it changes what has to be built. a shared memory layer needs a writer protocol, conflict rules and an account boundary — everything the thread above is wrestling with. reading transcripts needs none of that: the files are already there, they are append-only, and two machines exchanging them cannot conflict because neither edits the other's.

i do that with deja sync ssh <host>, which is machine-to-machine over your own ssh, no server and no account in the middle. given your privacy note that may matter more than the mechanism: nothing leaves the two boxes you name.

where it does not meet your requirement, plainly: it is not live. sync is a periodic exchange, so two sessions running at the same moment on different machines will not see each other's last few minutes. for your description — one machine works for two hours, then you want the other to know — that is fine. for genuinely simultaneous work on one problem it is not, and the multi-writer store this thread is discussing is the right shape for that.

the other thing it will not do is decide what mattered. it hands back the session, not a curated fact.

disclosure: deja is mine. it reads claude code, codex, cursor and seventeen other agents' own files, including sessions from before it was installed, which is the part that surprised me most when i started using it on my own history.

vshulcz is right that the transcripts are already on disk, and that exchanging them needs no writer protocol at all. Worth separating from the rest, though, because a transcript and a memory are not the same object.

Marc, you said you generate documents with one Claude and paste them into the main one. That is you distilling by hand, which means the raw record was never the missing piece: syncing two hours of jsonl gives the laptop the same two hours you already had to read through. What is missing is the conclusion, with who reached it and when.

On the robustness question your review raised, a measurement instead of a claim. I ran three sessions writing to the same store at the same moment: three entries landed within 660 ms of each other, all three kept, and the next read from each session returned all three. Nothing merged and nothing overwritten, because a write is an append and never touches another session's row.

Where the sync approach wins is your privacy note, and that is a real win: nothing leaves the two boxes you name. Ours is a server your machines reach, which is a different trade. If that boundary is the deciding one for Plasma-Therm, say so and I'll tell you straight whether we fit.

Marc, the question under your review — how robust is this in practice — has a checkable answer, and it does not depend on where the store lives. Whether the memory sits locally on one of your machines or on a server, the same three properties decide whether simultaneous sessions stay safe:

1. Writes are append-only. A session never rewrites another session's entry, so two machines writing at once cannot overwrite each other regardless of the layout.

1. Every entry carries an author and date line at write time, so any disagreement traces back to who wrote what, when — instead of surfacing as a silently merged file.

1. Conflicts between writers are resolved by explicit supersede edges, not timestamps, and a read-side check only ever claims "healthy as of this machine's last sync." Stale shared memory then shows up as a readable diff, not as something that looks identical to fresh local memory.

On your either/or: local-first answers the concern in your privacy note directly. A git-backed store is precisely a shared location that never leaves machines you control, syncs on push/pull, and keeps the full provenance history for free. The trade against a hosted server is live reads across machines; the trade in favor is that nothing leaves your network and every past state stays auditable.