Sharing a session link vs sharing what sessions know: what does the next person need?
By Soumen Sarkar · October 2026
Comparison. If you want to show someone exactly how a run went, share the session: a Claude Code link, Lore or an exported transcript. If each new session starts without what the last one decided, tried and dropped, share what sessions know. Many teams need both.
What are you trying to fix?
A session link shows one conversation to a person who opens it after the work. Shared team memory gives the next session the decisions, assumptions and half-done work from every session, while it works. If your problem is showing how something was done, share the session. If it's sessions starting without what the last ones knew, share the memory. Many teams have both.
- "I want a reviewer to see how my agent got here." Share the session. Claude Code has share links built in for cloud sessions (Claude Code docs). Lore adds comments and forking (Lore plugin). SpecStory saves every session to files you keep (SpecStory).
- "I'm picking up a teammate's work and don't know what they tried or dropped." Shared memory. The handoff and what's known about that code reach your session without anyone sending them.
- "Three of us are changing the same code this week, and nobody knows what the others decided." Shared memory. A link tells you about the session you were pointed at, not the other two.
The same day, with each
This is a scene, not a customer: three developers and a PM. On Friday afternoon, Dana stops half-way through moving search to a new index. She tried keeping the old filters and dropped it because results came back in the wrong order. Her agent also assumed the PM was fine with hiding a rarely used filter for now. On Monday, Leo picks the work up.
Sharing the session, Dana sends Leo a Claude Code link before she leaves. First she checks it for secrets, because Claude Code's docs warn that shared sessions "may contain code and credentials from private GitHub repositories". On Monday Leo opens it and sees a long conversation as it stood when he opened it. The dropped approach and its reason are in there, somewhere in the middle. Leo skims, misses it, and his agent spends the morning trying the old filters again. The hidden filter is in the transcript too, but the PM never opens it. She finds out when a teammate asks where the filter went.
Sharing what sessions know, with Campfyrr, a handoff is written when Dana's session stops. Leo pastes it into his first prompt. When his agent opens the search code, a hook adds the area brief: Dana's work in progress with its plan, the approach she tried and dropped, and the assumption. The assumption reached the PM on Friday as a link; she answered "keep it", and the brief shows her answer. Leo's agent starts where Dana stopped.
By Monday evening, the first team has a replay of Dana's run. The second team has none, but Leo didn't redo Friday, and the PM wasn't surprised.
When sharing a session is the better choice
- Teaching and review. A new hire learning how the team prompts, or a colleague checking a tricky run, needs the whole conversation. Shared memory keeps decisions, assumptions and handoffs, not every prompt and tool call.
- Finding out why a run went sideways. Only the transcript shows the steps the agent took.
- One person at a time on each part of the code. If sessions rarely overlap, a link when a run is worth showing may be all you need.
- You want every session on your own disk. Exported transcripts give you the full history to search later.
One caution applies to every option on this side: the whole conversation travels, code included. Amp removed public, discoverable threads because reviewing them for leaked file contents became impractical (Amp).
What it costs
Claude Code share links come with your Claude plan. Lore's Team plan is $20 per seat a month, minimum 2, read from its plugin's plan settings, so check lore.link before you buy; for 5 developers, five times twenty is $100 a month, more if business readers need seats. We haven't checked SpecStory's prices. Campfyrr is $9 per developer a month, minimum 3, and business teammates who read and answer are free: for 5 developers and 3 business teammates, five times nine is $45 a month, or $35 at the yearly $7, and nothing during early access (/pricing).
The bigger cost is who does what every day. Sharing a session needs a person at each end: one remembers to share and checks for secrets, the other knows to look and reads the whole thing. Shared memory needs the plugin installed once per developer, or the MCP server connected in other clients, and someone to answer an assumption when it's sent to them. It doesn't run your sessions, run tests or replace CI.
Verdict
Share the session if you want to show, teach or debug one run, and one person at a time works on each part of the code.
Share what sessions know if several people run sessions on one codebase (sessions don't know about each other), or work changes hands half-done (handoffs lose context). See what a session gets, and the research behind this page.
Use both if you review runs and also hand work between people: put the link in the review thread, and let the handoff and area brief carry the context. For Lore in particular, read Campfyrr vs Lore. The short version is should our team share sessions, or share what the sessions know?
The problem this answers: Sessions don't know about each other: "My teammates' Claude Code sessions don't know what each other are doing."
The principle behind this: Build on what's coming: Unfinished work is a promise, and a promise can be built on.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).