Learn how Lore captures coding-agent sessions, turns them into reusable context, and gives teams a shared library for skills and engineering decisions.
Lore allows you to upload and share Claude Code, Cowork, Codex, and Amp sessions. This means you can:
Start a project or investigation and hand it off to someone else.
Hand off a session to a different agent or harness.
Fork a session and take it in a different direction (preserving context from previous messages) without polluting the original session.
Archive your thinking and explorations for future reference.
Lore also deterministically indexes every session, so you can filter and search through them (and your team's sessions) much faster than if you asked your agent to search through them on your own computer.
The macOS app lets you opt into automatically uploading sessions from the agents on your computer as you work. This is a one-time configuration (which you can later turn off or reconfigure). See the overview for details.
Type /lore:share inside any Claude Code or Cowork session with the Lore plugin installed. Lore uploads the current session and returns a shareable URL, copied to your clipboard. In Codex, type $lore:share. In Amp, use the command palette entry Lore: Share active Amp thread instead.
You can share the same session multiple times. Lore deduplicates by session ID, so re-sharing is safe and won't create duplicates.
/lore:share is a deliberate action, so it bypasses any upload filters you've configured.
If you have the CLI installed, ask your agent to the current session by running lore export. For agents that store sessions separately, use the matching command:
lore export# share the current Claude Code session
lore share-cowork # share a Cowork session
lore export is a deliberate action, so it bypasses any upload filters you've configured.
By default, a session you share follows your Share new threads with my workspace setting (Settings → Account), which is on by default. So if you belong to a workspace, your shares start at workspace visibility (anyone with the same email domain); if you're not in a workspace or you turn the setting off, they start private. Plugin shares always use this default; to pick a different level, share from the CLI with --visibility or change the thread afterwards from its Share menu.
From the CLI, you can control visibility explicitly:
lore export --visibility private # only you
lore export --visibility workspace # your team
lore export --visibility public # anyone with the URL
See Data Privacy for a full explanation of the three visibility levels.
❦ Reading Threads ❦
Lore threads are searchable and retrievable from inside your coding agent, from the web, or from the command line.
Visit lore.link to browse your threads visually. The web UI shows thread previews, lets you filter by workspace member, and links directly to shareable URLs.
The CLI provides commands for fetching, searching, and listing threads directly:
lore threads get th_abc123
lore threads get https://lore.link/thread/th_abc123
lore threads ask "how did we handle auth token refresh?"
To list recent threads with optional filters:
lore threads list
# threads touching specific paths
lore threads list --filepath_prefixes src/auth,src/api
# threads from a time range (Unix timestamps)
lore threads list --created_at 1746057600...1746662400
# combine filters (ANDed together)
lore threads list --filepath_prefixes src/auth --created_at 1746057600
Filters AND together server-side. Multiple values within --filepath_prefixes are comma-separated and ORed. Output is JSON when stdout is not a TTY, making it easy to pipe into jq or other tools.
❦ Searching Threads ❦
There are two distinct ways to find things in Lore: quick search, a fast lookup by name, and Ask your threads, which answers questions across your team's history. Knowing which to reach for saves time.
For anything you can't answer with a title, ask a question. The Ask your threads row at the top of quick search takes your query to the ask flow, or use the CLI:
lore threads ask "how did we handle auth token refresh?"
Ask is a search agent, not a keyword box. It plans the query, applies any concrete constraints it finds (author, time range, skills, slash commands, file paths) as exact filters, retrieves candidates with combined full-text and semantic ranking weighted toward recent activity, and then writes a grounded answer that cites the source threads it drew from. If your question names a person, Lore resolves them to a real workspace member first; if nothing in your threads supports an answer, it says so rather than guessing.
Under the hood, ask searches thread titles, summaries, decision summaries, and the human side of transcripts (your prompts and plans). It doesn't index raw assistant output, so it finds threads by what they were about, not by every string the agent ever printed.
Asking a question doesn't just return an answer; it starts a real Lore thread. Ask Lore in the sidebar (or the Ask row in quick search) opens a new thread, streams the answer with its citations, and records the search steps in the transcript, so you can see what was searched and why. Follow-up questions continue the same conversation with context, and the thread gets an automatic title and summary like any other. These chat threads follow your normal default visibility, so in a workspace they're shareable team artifacts by default.
You can also make them multiplayer: add teammates to a Lore thread from the avatar bar at the top. Participants can read and reply even when the thread is otherwise private, and once more people are in the thread, Lore stays quiet unless a message mentions @lore, so a thread can double as a discussion with your team's history one mention away.
The threads feed has filter dropdowns for narrowing by author, repository, decision kind, and, for threads uploaded via the API, upload key and metadata. Filters combine, so "this repo, this person" is two clicks.
lore threads list supports filtering by author, file path prefix, and creation date, plus a title keyword match; run lore threads list --help for the full set (flags are generated from the API contract, so help is always accurate for your version). lore threads ask is the same ask flow described above.
Inside your coding agent, /lore:read fetches a thread by ID or URL, lists recent workspace threads, and searches threads by title keywords. For open-ended questions, prefer lore threads ask.
❦ Forking Threads ❦
Forking lets you continue work from an existing thread. Instead of reading the raw transcript, the agent receives a distilled handoff summary tailored to what you're about to do.
Forking is available in the Lore plugin (the /lore:fork command shown below) and from the CLI (lore threads fork).
/lore:fork https://lore.link/thread/th_abc123 add rate limiting to the auth endpoint
Lore fetches the thread, generates a context summary shaped around your intent, and loads it into the agent's context. The agent can then continue from where the thread left off.
/lore:read (plugin) or lore threads get (CLI) fetches thread content for inspection. This is useful for understanding what happened, reviewing decisions, or referencing prior work.
/lore:fork (plugin) or lore threads fork (CLI) fetches a distilled summary optimized for continuing work. The intent you provide tells Lore what to emphasize, so you get focused context rather than the full transcript.
The intent you pass to /lore:fork shapes what gets surfaced. If you're debugging a performance issue versus adding a new feature, the relevant context is different even in the same thread. Being specific about your intent gives you a more useful handoff.
Picking up a coworker's investigation: fork their thread with the intent of resolving the issue they were diagnosing
Continuing a debugging session: fork your own thread from yesterday to resume where you left off
Building on a prototype: fork a thread where someone explored an approach, with the intent of turning it into production code
Reviewing before a PR: fork a thread to understand the decisions behind a change before reviewing the diff
❦ Skills ❦
A skill is a reusable set of instructions your coding agent can invoke: a SKILL.md file whose frontmatter carries its name and description. Skills are where a team's working knowledge lives, and Lore turns the skills scattered across everyone's machines into a shared, synced catalog.
Lore discovers skills in the standard locations: ~/.claude/skills and ~/.config/agents/skills globally, .claude/skills and .agents/skills inside your projects, plus skills installed in Cowork.
Your Skills shows your personal skills. This tab needs the desktop app (it scans your local skill folders); in a plain browser it offers the app download instead. With the desktop app running, skills from your repos sync into this tab automatically as you add or edit them; there's nothing to import by hand. On Your Computer contains global and project skills from the file system on your computer. In Cowork contains skills managed by Claude Cowork; Lore can share them but can't update them. Each skill's detail pane has a Share button for visibility, invites, links, and customizable copies.
Team Skills is your workspace's shared catalog. Each skill shows its published version history and rich-text content. In the desktop app you can install a skill straight from here; downloaded team skills remain in this tab rather than also appearing under Your Skills. On the web the same button hands off to the app.
Shared with you lists public skills you've installed or copied from share links, from people outside your workspace.
Select Share in a personal skill's detail pane to make it private, workspace-visible, or public; invite specific people by email; or publish an anonymized copy that recipients can customize. The first time you change one of these sharing settings, Lore saves the skill automatically before applying the setting. Merely opening the dialog does not save it.
You can also publish from the CLI:
lore skills publish <name>
You stay the owner: only you can push updates directly, change visibility, invite people, or unpublish the skill. Workspace sharing requires belonging to a workspace.
One thing to know: Lore syncs the SKILL.md file itself. If your skill folder bundles extra scripts or resources, those don't upload.
Install from the Team Skills tab in the desktop app, or from the CLI:
lore skills install <skill_id>
The skill is written to ~/.claude/skills/<name>/SKILL.md, where your coding agents pick it up. Installs never overwrite an existing file Lore doesn't manage; if you already have an unmanaged skill by the same name, the install is refused instead of clobbering it.
Sync is two-way, and the background daemon runs it continuously, so in practice you rarely need to invoke it by hand:
Installed workspace skills update to the owner's latest accepted version.
Your local edits to skills you own upload automatically as new versions.
Public skills from outside your workspace stay pinned to the version you installed; they never change under you.
If both your copy and the remote changed since the last sync, Lore flags a conflict and touches nothing; resolve it manually and re-publish. lore skills status shows per-skill sync state.
If you've installed a skill someone else owns, you can still improve it: publishing your edit creates a proposed version and notifies the owner. Owners review proposals from the CLI:
lore skills proposals <skill_id> # list pending proposals
lore skills approve <skill_id> --version <version> # accept; becomes the new latest
lore skills reject <skill_id> --version <version> # decline, optionally with --reason
Versions are timestamps rather than semver, the full history is kept, and re-publishing identical content is deduplicated instead of creating a noise version.
A skill's owner can set its visibility to private (just you), workspace (your team's catalog), or public. Public skills get a share link. Signed-out visitors see only the name, description, and owner; signing in unlocks the full skill body and the ability to copy or install it. Skills you pick up this way appear in your Shared with you tab.
Threads record which skills the agent invoked and which slash commands you typed during the session. The first invoked skill appears as a badge on the thread list, each invocation renders inline in the transcript, and the Team Skills usage counts are computed from these records, so you can see how a skill actually performs in real work. Ask your threads can also filter by skill.
Cowork skills appear under In Cowork on the Your Skills tab. Lore can share them but can't update them.
Unpublishing removes a skill from the catalog but leaves your local file untouched.
For scripting, lore skills list prints the catalog and lore skills scan prints your local skills, both as JSON.
❦ Account Settings ❦
Your account-level settings live on the web at lore.link, under Settings → Account. This page is where the "account sharing preference" referenced throughout these docs actually lives.
This is the setting that determines the default visibility of threads you upload. It is on by default.
On: threads you upload start out visible to everyone in your workspace.
Off: threads start out private until you share them.
The effective default also depends on whether you're in a workspace at all: if you don't belong to one, new threads are private regardless. The same preference is applied by every upload path (the background daemon, lore export, the plugin's /lore:share, and the MCP share_session tool). See Data Privacy for the full rule.
The toggle requires belonging to a workspace; without one it's shown but inert, since there's no workspace to share to.
You don't have to change the default to adjust one thread. Open any thread at lore.link and use its Share menu to set that thread to Private, your workspace, or Public. The workspace option appears when you belong to a workspace; Private and Public are always available.
Background uploads depend on a few things lining up. Check them in order:
Are you signed in? Run lore whoami. If it doesn't show your account, run lore login.
Is the daemon running and healthy? Run lore status and check Enabled, Healthy, Last heartbeat, Last success, Last error, and Process running. A stale heartbeat or a populated Last error points at the problem.
Do your upload filters allow anything? The daemon reads ~/.lore/upload-filters.json, and an empty or missing include allowlist uploads no Claude Code sessions. Run lore configure to pick directories, or add cwd/repo rules. See Data Privacy.
Is the directory watched? Run lore listen list to confirm the path is in the watch set.
Are you on macOS? The background daemon runs only on macOS (see below).
Logs are at ~/.lore/upload.log.txt (daemon) and ~/.lore/cli.log.txt (CLI) if you need detail.
The background daemon is macOS-only; lore enable will report that it's unsupported on other platforms. On Linux and Windows, share on demand instead with lore export (or /lore:share from the plugin), which works everywhere.
Access tokens are short-lived and refreshed automatically. If your refresh token has expired or been invalidated, the CLI clears the session (an invalid_grant from the auth server). The fix is to run lore login again. Credentials are stored at ~/.lore/tokens.json with owner-only (0600) permissions.
The first time you use the plugin it walks you through an OAuth sign-in. If it didn't complete (for example, the browser didn't open), re-run the plugin's login step to get a fresh verification link and code. In Claude Code you can also re-run /mcp to complete authentication for the Lore server.
Workspace auto-grouping is keyed by verified company email domain. Public email domains (gmail.com, outlook.com, yahoo.com, icloud.com, and many others) are excluded, so signups on personal email don't get pooled into a shared workspace. Have teammates sign up with their company email to land in the same workspace.
The API returns 404 (never 403) for a thread you can't see, so it never reveals whether a hidden thread exists. A 404 can therefore mean the thread doesn't exist, or that it does but isn't visible to you, or that you're not signed in. Check that you're authenticated and that the thread's visibility includes you.
Network errors like ECONNREFUSED or ENOTFOUND mean the client couldn't reach Lore's API. Check your connection and any corporate proxy or firewall, then retry. The CLI retries transient connection failures automatically.
