Claude Code / Multi-Session
Your terminals just started
talking to each other.
In Claude Code v2.1.224, a session running your backend can now send a message directly to the session running your frontend. But strictly speaking, this isn't "shared memory" — it's message passing. Here's what actually changed, and what didn't.
The Problem
Two parallel sessions used to know
nothing about each other
Running Claude Code in parallel across multiple terminals — say, one on a backend API and another on the frontend that calls it — has always meant each session worked in total isolation. Change a spec in one session, and the other keeps working without any idea it happened. Developers had to bounce between terminals and manually relay the information themselves.
Claude Code v2.1.224, released August 7, is the first update to directly address this "gap between sessions."
How It Works
What gets passed is a message,
not memory
You tell Claude what you want the other session to know, and Claude writes a summary that gets delivered to it.
Between sessions on the same machine, delivery happens locally. Across different machines, it routes through Anthropic's servers instead. According to The Decoder's report, safety guardrails are baked in specifically so the feature can't be repurposed for something dangerous: a delivered message can't approve permission requests on your behalf, and it can't change configuration. Slash commands like /compact arrive as plain text rather than as an executable instruction.
Correction
It's easy to misread this as
"shared memory" — it isn't
The daily_updates headline reads like "sessions now share memory," but that's not quite accurate. As The Decoder explicitly points out, sessions don't share each other's conversation history, context state, or file contents. What actually gets passed is a text message, nothing more. Worth noting: this is a separate feature from "Session Memory," which automatically remembers a single session's own past work — the two are easy to conflate but aren't the same thing.
So What
Who should use this, and how
Why this matters now. It's a first step for agentic coding tools moving from "one user drives one session" toward coordinating several sessions running in parallel. Parallel-worktree development gets a bit closer to genuine division of labor.
Who benefits, and how. Engineers running multiple worktrees in parallel, or working backend and frontend simultaneously in separate terminals, get a real reduction in manual information-relaying. If you work in a single window on a single task, this feature has nothing for you yet. Roles like PM or QA, who need a rolled-up view of progress across sessions multiple engineers have started, could also benefit — a message log lowers the cost of keeping track of what's going on.
What to do next. Three realistic first steps: (1) start with a simple case — two sessions on the same machine, passing one finding from one to the other; (2) if you need cross-machine coordination, remember it routes through Anthropic's servers and avoid relaying anything sensitive; (3) if your team uses this, agree on ground rules for what's okay to relay. Practical use cases already being suggested include a long-running batch-processing session pinging another with a "done" progress notification, or one session handing off the root cause of a bug it just found directly to the session doing the fix.
Counterpoint and risk. Blocking permission approval and config changes is the safe design choice, but how much to trust the actual content of a delivered text message is still left to the user's judgment. What happens if a relayed message contains a malicious prompt injection hasn't been thoroughly tested as of this writing. And since Windows isn't supported yet, Windows developers don't get this benefit for now. Since cross-machine messages route through Anthropic's servers, it's worth avoiding a habit of relaying entire chunks of confidential code or logs through this channel.
What got shared wasn't memory —
it was one line about what's happening right now.