You finished a Claude Code session that solved something hard. Now you want a teammate to see it. Most people try one of three things, and all three lose information.
This guide covers the actual ways to share a Claude Code session, what trade-offs each one has, and how to make sharing a habit your team can actually rely on.
What people try first (and why it falls short)
Pasting the transcript into Slack. The thread is too long, the formatting collapses, code blocks survive but tool calls don't, and the conversation now lives in a channel that scrolls off in a week. Searchable only by string match, never by meaning.
Screenshotting the interesting parts. Easy to send, impossible to read three weeks later. A screenshot can't be searched, can't be diffed, can't be replied to in context. It also strips out everything that didn't fit in the visible window: usually the prompts that led to the breakthrough.
Writing it up in Notion. This is the "right" answer, except it never happens. By the time you've context-switched to writing the doc, you've forgotten the three approaches you rejected and the constraint you discovered halfway through. What ends up in Notion is a sanitized summary, not the reasoning.
The shared problem: each of these reduces the session to something less than what actually happened. The value of a Claude Code session is the reasoning: the prompts you tried, the dead ends you ruled out, the constraint that surfaced mid-conversation. That's the part that costs the most to recover later.
Install the Lore CLI
The /share command is a Claude Code skill that ships with the Tanagram CLI. One-time setup, two commands:
npm install -g @tanagram/lore
lore login
The login step opens a browser, drops you onto lore.link, and finishes the auth flow. As a side effect, the postinstall step adds the /share skill to ~/.claude/skills, so it shows up the next time you open Claude Code. No extra wiring.
If your team has a Tanagram workspace already, signing in with the same email domain automatically puts you in it. If not, signing in creates one for that domain.
What /share does
Inside any Claude Code session, run /share. The skill exports the thread (every message, every tool call, every diff, every image) and returns a shareable URL. Anyone with the link can open it in a browser. The full conversation renders the way you saw it: turns in order, tool calls collapsible, code with syntax highlighting, diffs side by side.
Nothing leaves your machine until you run the command. You can edit the title before publishing, trim messages you don't want to share, and choose who can see it.
Three visibility modes:
- Private: only you. Useful for personal archives or for trying out
/share before showing a teammate.
- Workspace: anyone in your Tanagram workspace with the same email domain. The default for team sharing.
- Public: anyone with the link. Use this when you want to send a Lore URL out of the company (in a PR description on a public repo, in a tweet, in a job interview).
You can change visibility on a thread after publishing, or delete a Lore URL at any time.
How to fit sharing into the workflows that matter
Sharing only works if it's tied to a habit your team already has. Three workflows where teams have made it stick:
PR review
Engineers paste a Lore URL into the PR description for any change where the why is more interesting than the what. A reviewer who wants to understand "why this approach over the obvious alternative" clicks the link and sees the reasoning that produced the code, including the alternatives that got ruled out.
This works because PR review is already where decisions get scrutinized. Adding a link in the description costs no new ritual.
Incident response
When something breaks and the fix lives inside a long Claude Code session, the engineer fixing it runs /share before closing the session. The Lore URL goes into the post-incident write-up or the Slack thread. Three months later, when someone asks "why does the retry logic look like this," the reasoning is one click away.
This works because incidents already produce write-ups, and incidents are exactly when you regret not capturing the reasoning.
Onboarding
New hires get a curated list of Lore URLs that represent how the team actually works: the auth refactor session, the migration that almost went wrong, the day someone discovered the production database had no indexes. Reading these is closer to pair-programming with the original engineer than any document a teammate has time to write.
This works because onboarding is permanently under-resourced. Lore URLs are zero-cost artifacts that already exist.
What gets stored, and what doesn't
The session content you choose to export is stored on Lore. Your local files outside the session are never uploaded. If you trim a message before publishing, the trimmed content is not stored. You can delete a Lore URL at any time and the underlying thread is removed.
Workspace and public threads are visible to the people in their visibility scope. Private threads are visible only to you.
If you're on the free tier, public links expire after 3 days. On the Team plan, they live forever. Both tiers support unlimited private and workspace threads.
When not to use it
/share exports what's already in the session. If half the reasoning happened in a face-to-face conversation and the session captures only the typing, the Lore URL won't include the conversation. Either narrate the trade-offs to Claude before you write code, or capture the rationale in a separate channel.
If the session contains secrets (a leaked API key, a customer name you weren't supposed to type), trim those messages before publishing, or keep the visibility private.
The smallest version of this
If you do nothing else, do this: the next time you finish a Claude Code session that resolved a non-trivial bug, run /share and paste the URL into the PR description. One link. Five seconds. Then watch what happens the next time a reviewer asks "why."
If the answer to "where does the reasoning live?" is "in a chat window I closed an hour ago," sharing is the first thing to fix.