{"slug": "how-to-turn-claude-code-transcripts-into-a-shareable-link", "title": "How to turn Claude Code transcripts into a shareable link", "summary": "Lore has built a `/share` command that turns Claude Code transcripts into shareable links, evolving from a social-network concept into a tool for PR context, handoffs, and observability. The architecture includes a plugin with skills, a local MCP server for on-device file access, and a remote MCP server orchestrating the API, overcoming early issues with context doubling by moving transcript reading to a local script. Lore also offers `/read` and `/fork` skills for applying others' work and generating intent-based summaries.", "body_md": "Lore started as a social network for AI prompts and sessions: perhaps these would be the 2026 equivalent of open-source Github repos. The `/share`\n\ncommand was step 1.\n\nWe've since evolved away from the social network idea, but `/share`\n\nremains useful for us and our early users:\n\n- We run it on every Claude Code session that creates a PR and add the Lore link to the corresponding PR for context.\n- Our users use it to hand off work — one person starts an investigation, and then passes it to someone else (or a different agent) to finish.\n- Some of our users are building their own skills/plugins as products distributed to\n*their*users, and use`/share`\n\n(or related components like our[SDK](https://www.npmjs.com/package/@loredotlink/sdk)) for observability on how well their products are working for their users.\n\nA lot of detail goes into that seemingly-simple command: table-stakes stuff like finding the right file on disk, reconciling repeated shares, and auth (the *other* four-letter word); quality-of-life stuff like automatically copying the shared link, letting you specify a title for the shared thread, and letting you specify blocks that you want to highlight in the shared link.\n\nLet's dive into how it's built and the lessons we learned along the way.\n\n## Architecture\n\n`/share`\n\nis made up of three main layers:\n\n- A skill, wrapped in a plugin, which is the command that users actually invoke (e.g. via\n`/share`\n\nin Claude Code or`$share`\n\nin Codex). - A local MCP server that implements on-device functionality (reading session files; copying the output URL to clipboard).\n- A remote MCP server that orchestrates our underlying API.\n\n### Plugin + Skill\n\n`/share`\n\nis a skill; its source is [on Github](https://github.com/loredotlink/lore-plugin/blob/main/skills/share/SKILL.md).\n\nThe first version of this skill just asked the agent to read its own session file and upload it to our API. This broke down quickly on real-world sessions: reading the session file immediately doubled the context usage of the agent, and that caused problems, especially when the agent tried to compact the resulting session.\n\nWe fixed this by adding a script that read a given transcript file from our computers' local filesystem and uploaded it; the skill would simply invoke this script. That script evolved into our [CLI](https://www.npmjs.com/package/@loredotlink/cli), and later into our local MCP server (more on this below).\n\nNow we had a skill which depended on a script, and we wanted an easy way to install them both. We bundled them into a [plugin](https://code.claude.com/docs/en/plugins); Claude and Codex provide built-in ways to install plugins. The plugin also namespaces our skills (so it's actually `/lore:share`\n\nand `$lore:share`\n\n), which was something that one of our early users requested.\n\nOur plugin now comes with two additional skills:\n\n, which lets you prompt something like \"look at what Matt did in thread th_123 and apply that on my system\".`/read`\n\n, which generates an`/fork`\n\n*intent-based summary*of an existing thread. Instead of generically summarizing threads up-front, which indiscriminately discard information, many Lore features summarize content for specific purposes (some of which are baked in; some of which, like this one, are user-supplied).\n\n### Local MCP Server\n\nLocal script/CLI hit a wall when we went to add support for Claude Cowork: Cowork sessions ran into a sandbox (originally on your computer, now [remotely by default](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview)). A script/CLI in this environment doesn't have access to your local filesystem, so it can't read transcript files.\n\nCowork uses the Claude Desktop app [as a bridge](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork#:~:text=Claude%20reaches%20it%20through%20the%20Claude%20Desktop%20app%20on%20that%20computer) to your local computer:\n\nLocal MCP servers bundled with plugins and desktop extensions run on your computer with the same permissions as any other program you run (\n\n[Source])\n\nWe converted our transcript-reading code into a local (stdio) MCP tool named `share_session`\n\n, and bundled that [into our plugin](https://github.com/loredotlink/lore-plugin/tree/main/server-src).\n\n`share_session`\n\nfinds the transcript file for your session on disk, uploads it to our server, gets back a URL, and then invokes a local copy command (e.g. `pbcopy`\n\non macOS) to automatically put it onto your clipboard.\n\nImportantly, the local MCP server is also responsible for authentication. It'll trigger a login flow when needed, and use that to retrieve and save a token to disk. Originally, we directly stored the OAuth access and refresh token we got back from our server, but refreshing auth tokens was unreliable and would occasionally require interrupting the user with a synchronous login flow. Fortunately, we had separately built an Upload API Key (UAK) system to support our [SDK](https://www.npmjs.com/package/@loredotlink/sdk) at the request of one of our users; we now programmatically generate a long-lived UAK upon initial login, and persist that value for future session uploads.\n\n### Hosted MCP Server\n\nWe technically didn't *need* the hosted MCP server … but we already had it, and it abstracts over our underlying API. For example, the remote `share_session`\n\ntool covers 11 steps:\n\n- Create an upload session.\n- Obtain a presigned storage URL to S3.\n- PUT the transcript bytes to that presigned URL.\n- Complete the upload session (which is the trigger for further server-side processing on the uploaded content).\n- Verify the content hash.\n- Create or update the thread.\n- Schedule parsing.\n- Apply title and visibility behavior.\n- Optionally wait for a background job to finish parsing the transcript and resolve a natural-language highlight.\n- Record plugin activation analytics.\n- Return a canonical absolute URL.\n\nAbstracting that away server-side makes our plugin bundle smaller and easier to evolve.\n\n### Repo\n\nThe `lore-plugin`\n\nrepo is [on Github](https://github.com/loredotlink/lore-plugin). It contains:\n\n- the contents of our\n[bundled skills](https://github.com/loredotlink/lore-plugin/tree/main/skills); - the\n[source](https://github.com/loredotlink/lore-plugin/tree/main/server-src)and[built artifact](https://github.com/loredotlink/lore-plugin/tree/main/server)of the local MCP server (a Bun binary); and - manifests for a\n[Claude](https://github.com/loredotlink/lore-plugin/tree/main/.claude-plugin)and[Codex](https://github.com/loredotlink/lore-plugin/tree/main/.codex-plugin)plugin. We also have an[plugin](https://github.com/loredotlink/lore-plugin/blob/main/amp/lore.ts)for[Amp](https://ampcode.com/), although this is experimental and not yet supported outside of our team.\n\nThis repo is a subtree mirrored out of our private monorepo, in which we do all our development. This monorepo setup allows us to rapidly make cross-cutting changes across our whole product; more on this on a later post.\n\n## Where We're Going\n\nThread sharing is a foundational piece of what we're building at Lore, but there's a lot more to come.\n\nWe believe that agents and AI-native workflows are resulting in new primitives. Before AI, work revolved around constructs like meetings, files, and runbooks/SOPs; AI-native workflows introduce threads, skills, and artifacts. Some of these have analogs in pre-AI constructs; others do not (or at least, not entirely). In both cases, AI-native teams and individuals will need the right tools to work with these new primitives. We don't yet know exactly what this will look like (capabilities and workflows are changing very quickly at the frontier), but we plan on building — for ourselves, and for knowledge workers at the frontier of what's possible — and finding out.\n\nIf this speaks to you, give [Lore a try](https://lore.link/) and let us know what you think.", "url": "https://wpnews.pro/news/how-to-turn-claude-code-transcripts-into-a-shareable-link", "canonical_source": "https://lore.link/blog/how-we-built-share", "published_at": "2026-07-24 22:42:17+00:00", "updated_at": "2026-07-24 22:52:17.659077+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-agents"], "entities": ["Lore", "Claude Code", "Codex", "Claude Desktop", "Claude Cowork"], "alternates": {"html": "https://wpnews.pro/news/how-to-turn-claude-code-transcripts-into-a-shareable-link", "markdown": "https://wpnews.pro/news/how-to-turn-claude-code-transcripts-into-a-shareable-link.md", "text": "https://wpnews.pro/news/how-to-turn-claude-code-transcripts-into-a-shareable-link.txt", "jsonld": "https://wpnews.pro/news/how-to-turn-claude-code-transcripts-into-a-shareable-link.jsonld"}}