# Lore > Run `/lore:share` inside any Claude Code or Cowork session (or `$lore:share` in Codex) and Lore turns the prompts, tool calls, and diffs into a URL your team can read. Free workspace plan. Lore is infrastructure for working with coding-agent threads, built by Tanagram, Inc. (Dover, Delaware, USA — founders@lore.link). Agent plugins and the desktop app upload threads, the web app at https://lore.link makes them browsable and searchable across a workspace, and a hosted MCP server (https://mcp.lore.link/mcp) gives agents the same access. New shares follow the user's **Share new threads with my workspace** setting, which is on by default: threads start at workspace visibility for workspace members and private visibility otherwise; public visibility is opt-in. Pricing: Free ($0), Team ($20 / seat / month), Enterprise (Custom). For the complete docs and product context in one fetch, read https://lore.link/llms-full.txt. ## Docs - [Docs index](https://lore.link/docs): documentation home - [Introduction](https://lore.link/docs/overview): what Lore is, the problem it solves, and how it works - [Using Lore](https://lore.link/docs/using-lore): sharing threads, visibility modes, and workspaces - [Using Workbench](https://lore.link/docs/using-workbench): the desktop agent: sessions, skills, attachments, sources, artifacts, forking, connectors ## Pages - [Homepage](https://lore.link/): product overview and quickstart - [Pricing](https://lore.link/pricing): Free ($0), Team ($20 / seat / month), Enterprise (Custom) - [Lore for Teams](https://lore.link/teams): team knowledge-sharing use cases - [Thread Sharing](https://lore.link/share): how shared threads work - [Desktop](https://lore.link/desktop): the macOS app - [Blog](https://lore.link/blog): articles on AI-assisted engineering - [Integrations](https://lore.link/integrations): supported coding agents - [Contact](https://lore.link/contact): contact form (or email founders@lore.link) - [Privacy Policy](https://lore.link/privacy): how thread data is handled - [Terms of Service](https://lore.link/terms): terms of service ## Integrations - [Lore for Claude Code](https://lore.link/integrations/claude-code): share with /lore:share - [Lore for Codex](https://lore.link/integrations/codex): share with $lore:share - [Lore for Cowork](https://lore.link/integrations/cowork): share with /lore:share ## Reference reading - [Lore Changelog #0010](https://lore.link/blog/lore-changelog-0010): by Matthew Molinar - [Lore Changelog #009](https://lore.link/blog/lore-changelog-0009): by Matthew Molinar - [How we built /share](https://lore.link/blog/how-we-built-share): by Feifan Zhou - [Lore Changelog #008](https://lore.link/blog/introducing-the-workbench): by Matthew Molinar - [ClaudeMaxxing to 100%: the code, the content, the research, the ops](https://lore.link/blog/claude-maxxing): by Kaia Colban - [Lore Changelog #007](https://lore.link/blog/introducing-lore-studio): by Matthew Molinar - [What shipped in Lore this week](https://lore.link/blog/decisions-skill-sharing-and-faster-search): by Matthew Molinar - [How a 3,000-person company got 95% of its employees using AI](https://lore.link/blog/how-a-3000-person-company-got-95-percent-using-ai): by Kaia Colban - [How I built AI memory (and accidentally built two)](https://lore.link/blog/how-i-built-ai-memory): by Kaia Colban - [Workslop is a context problem, not an AI problem](https://lore.link/blog/workslop-context-problem): by Kaia Colban - [Lore Updates #0006](https://lore.link/blog/skill-publishing-multiplayer-threads-and-first-class-artifacts): by Matthew Molinar - [How Cowork Implements Skills](https://lore.link/blog/how-cowork-implements-skills): by Feifan Zhou - [Stuff nobody tells you about Claude skills](https://lore.link/blog/stuff-nobody-tells-you-about-claude-skills): by Kaia Colban - [What I learned sharing a Claude skill with my team](https://lore.link/blog/sharing-a-claude-skill-with-my-team): by Kaia Colban - [Lore Changelog #0005](https://lore.link/blog/smoother-sync-skills-and-desktop-stability): by Matthew Molinar - [Lore vs. Claudebin: sharing a Claude Code session as a URL](https://lore.link/blog/lore-vs-claudebin): by Paulina Laba - [Lore Changelog #0004](https://lore.link/blog/lore-mac-app-and-lore-link): by Matthew Molinar - [AI made you faster. It made your team slower.](https://lore.link/blog/ai-made-you-faster-team-slower): by Kaia Colban - [Lore Changelog #0003](https://lore.link/blog/conversational-threads-streaming-answers-and-a-faster-app): by Matthew Molinar - [Your Team Is in Claude All Day. Where Does That Thinking Go?](https://lore.link/blog/where-does-your-teams-claude-thinking-go): by Kaia Colban - [AI engineering knowledge management: a guide for 2026](https://lore.link/blog/ai-engineering-knowledge-management-guide): by Paulina Laba - [The reasoning behind your code exists. Your team just can't find it.](https://lore.link/blog/ai-generated-code-reasoning-findable): by Kaia Colban - [The best ways to share a Claude Code session (2026)](https://lore.link/blog/best-ways-to-share-a-claude-code-session): by Paulina Laba - [How to fork a Claude Code or Codex session](https://lore.link/blog/fork-claude-code-codex-session): by Paulina Laba - [How to onboard engineers in the AI era](https://lore.link/blog/how-to-onboard-engineers-in-the-ai-era): by Paulina Laba - [Lore vs. Braintrust: what each does and when to use which](https://lore.link/blog/lore-vs-braintrust): by Paulina Laba - [Lore vs. LangSmith: what each does and when to use which](https://lore.link/blog/lore-vs-langsmith): by Paulina Laba - [Lore vs. ShareGPT: sharing AI chats vs. sharing coding sessions](https://lore.link/blog/lore-vs-sharegpt): by Paulina Laba - [How to save your favorite prompts from Claude Code and Codex](https://lore.link/blog/save-favorite-prompts-claude-code): by Paulina Laba - [Lore Changelog #0002](https://lore.link/blog/ask-lore-smarter-sharing-and-plugin-skills): by Feifan Zhou - [I Gave Up Solo Building to Join Tanagram.](https://lore.link/blog/solo-building-to-tanagram): by Kaia Colban - ['AI teams merge 98% more PRs.' What that's doing to your code.](https://lore.link/blog/ai-pr-velocity-quality-tradeoff): by Kaia Colban - [Lore Changelog #0001](https://lore.link/blog/regions-upload-filters-and-direct-thread-links): by Feifan Zhou - [Prompt tracking vs. AI session sharing: what to use when](https://lore.link/blog/prompt-tracking-vs-ai-session-sharing): by Paulina Laba - [AI made me a faster engineer. It didn't make us a better team.](https://lore.link/blog/ai-faster-engineer-not-better-team): by Kaia Colban - [Managing Tribal Knowledge for Engineers: A Practical Guide](https://lore.link/blog/managing-tribal-knowledge-for-engineers-a-practical-guide): by Kaia Colban ## Machine-readable resources - [Machine-readable pricing](https://lore.link/pricing.md): parseable markdown for AI agents - [XML sitemap](https://lore.link/sitemap.xml): every indexable page - [MCP server](https://mcp.lore.link/mcp): streamable-HTTP Model Context Protocol endpoint - [OpenAPI specification](https://lore.link/openapi.json): public REST API - [llms-full.txt](https://lore.link/llms-full.txt): this index plus product context and the complete docs inlined --- # Product context ## What Lore is Lore is infrastructure for working with coding-agent threads. It preserves the context behind useful threads, makes those threads searchable, and enables several use cases built on top of this data: - Agent plugins and a desktop app that share and automatically upload threads. - A collection of skills for sharing and working with threads directly inside coding agents. - A web service for browsing your threads and managing federated sharing permissions. ## Quickstart 1. Install the Lore plugin for your coding agent, or install the desktop app. 2. Run `/lore:share` inside a Claude Code or Cowork session — or `$lore:share` inside a Codex session — to get a shareable URL. 3. Have your teammates sign up — users with the same email domain are automatically added to your workspace. ## What Lore is for - **Sharing AI coding sessions.** Drop a Lore URL into a PR description, a Slack channel, or a Linear ticket. The recipient sees the full thread — prompts, tool calls, diffs, images — rendered in the browser. - **Building a searchable library** of valuable agent threads across an individual or a workspace. - **Skill development.** See how users actually invoke your skill or plugin in real Claude Code, Codex, or Cowork sessions, instead of inferring from copy-pasted screenshots. - **Onboarding.** New hires read curated Lore URLs that represent how the team actually works, instead of waiting for a teammate to find time to write a doc. ## What Lore is NOT - **Lore is not LLM API call logging.** Tools like PromptLayer, Helicone, Langfuse, and LangSmith sit between an application and an LLM API and log every request. Lore captures the back-and-forth between a human engineer and a coding agent. Different unit of work, different audience. See: https://lore.link/blog/prompt-tracking-vs-ai-session-sharing for the difference. - **Lore is not a chat history viewer.** It does not aggregate every message you have ever sent to Claude. It exports the sessions you explicitly choose to share, with the visibility you choose. - **Lore is not a documentation tool.** It does not replace ADRs, runbooks, or design docs. It preserves the reasoning that produced the code, and link out to the docs that interpret that reasoning later. ## How Lore compares to common alternatives People often try one of these before they try Lore: - **Pasting the transcript into Slack.** Loses formatting, loses tool calls, scrolls off the channel in a week. Not searchable by meaning, only by string match. - **Screenshotting the interesting parts.** Loses everything that didn't fit in the visible window — usually the prompts that led to the breakthrough. Not searchable at all. - **Writing it up in Notion.** Loses the reasoning. By the time someone writes the doc, the context is stale and what ends up in Notion is a sanitized summary. - **Pasting into a Gist.** Better than the above, but Gists strip tool calls, lose diffs, and don't render an agent thread well. Also not searchable across a team. A Lore URL keeps the thread intact, renders it in the browser the way it played out, and stays searchable across the workspace. ## Privacy New threads follow your **Share new threads with my workspace** account setting, which is on by default. If you belong to a workspace, new shares normally start at `workspace` visibility. If you do not belong to a workspace or turn the setting off, they start `private`. Visibility modes: - `private` — visible only to you. - `workspace` — visible to teammates with the same email domain. - `public` — visible to anyone with the URL. You can rename a session, change its visibility, or delete any Lore URL at any time. Local files outside the recorded agent session are never uploaded. ## Pricing - **Free** — $0. Upload and sync skills across your team; Visibility and editing permissions; Security scanning on every publish. - **Team** — $20 / seat / month. Everything in Free; Usage analytics: see who's using which skills and how often; Smart analytics: catch failing skills and output churn, and surface skills worth creating; Automatic regression alerts when a skill version changes; Google SSO; Zero data retention on AI usage; AI usage included, with usage-based pricing for overage. - **Enterprise** — Custom. Everything in Team, with volume discounts; Bring your own storage for transcripts; Additional SSO providers; Advanced governance and admin controls. Subscriptions cancel at the end of the current billing period; existing skills and shared links keep working at your current tier until the period ends. Machine-readable pricing for AI agents: https://lore.link/pricing.md ## Programmatic access Lore is scriptable and agent-connectable: - **MCP server** — a hosted Model Context Protocol server at https://mcp.lore.link/mcp lets any MCP-capable agent read, search, and create Lore threads. Tools: `list_threads`, `get_thread`, `search_threads`, `fork_thread`, `share_session`. Add it to Claude Code with `claude mcp add --transport http lore https://mcp.lore.link/mcp`. - **REST API** — a typed OAuth API for reading and searching visible threads. Use https://lore.link/auth.md for discovery and authentication details. ## Company Lore is built by Tanagram, Inc., a company based in Dover, Delaware, USA. It is made by a small team you can reach directly: use the form at https://lore.link/contact or email founders@lore.link. --- # Full documentation ## Introduction: Start Here With Lore, we help teams organize AI work, instead of it living on one person's computer and disappearing. We gather every prompt, skill, and AI session and turn it into searchable, shareable infrastructure. Lore preserves the context behind useful threads and enables several use cases built on top of this data. We initially built Lore to share our Claude threads with each other: as contextual links on PRs, snapshotting some research or investigating for someone else to pick up, or just "check out this cool thing I did." Since then, we've run into many other use cases, and built a whole product around this primitive. You can sign up on [web](/login) or in the [macOS app](/desktop). Your teammates can join just by signing up; we'll automatically add users with the same email domain to your workspace (users with gmail.com and other individual email domains will get their own individual workspaces). # Install Lore The macOS desktop app lets you browse Lore in its own window. Install the plugin separately for explicit sharing and reading from your coding agents.

The desktop app is the easiest way to get started, and it needs no terminal. It's a native macOS app that lets you browse Lore in its own window.

Download the macOS app

  1. Download it from lore.link/desktop and drag Lore into Applications.
  2. Sign in through your system browser.

That's it. The app keeps itself up to date and hands you off to Lore.

First run

First run is sign-in only:

  1. Sign in. The app opens your system browser for sign-in (the same account flow as the web app) and returns you to the app automatically.

After sign-in, the desktop app hands you off to the hosted Lore app. Install the Lore plugin with the instructions in the next tab, then use its share command when you want to upload a session.

# Privacy Lore threads can be in one of three privacy settings: - `private` is visible only to you. - `workspace` is visible to your team (anyone logged in with your same email domain). - `public` is visible to anyone with the URL. New threads default to `workspace` if you belong to a team workspace and haven't turned off the **Share new threads with my workspace** setting (on by default). If you're not in a workspace, or you turn that setting off, new threads default to `private`. --- ## Introduction: Concepts A quick tour of the nouns you'll see throughout these docs. # Sessions and threads A **session** is the local transcript your coding agent produces as you work: the running record of messages, tool calls, and file edits inside Claude Code, Cowork, Claude Desktop, or Amp. A **thread** is that session persisted to Lore. When you share or upload a session, Lore stores the transcript, parses it, gives it a title, and makes it searchable and shareable. Thread IDs start with `th_`, and every thread has a URL like `https://lore.link/thread/th_...`. In short: a session is the thing on your machine; a thread is the thing in Lore. # What a thread contains Beyond the raw transcript, each thread carries: - The **messages and tool calls** from the session, broken into blocks. - The **file paths touched** during the session, so threads are searchable by code area. - The **harness** it came from and the originating session ID. - A **title** (auto-generated, or one you set when sharing), the **author**, and timestamps. - The **skills and slash commands** invoked during the session. - A **visibility** setting (`private`, `workspace`, or `public`). See [Data Privacy](/docs/data-privacy#article-data-privacy). # Skills and the skills library A **skill** is a reusable set of instructions your coding agent can invoke, like a slash command or a saved workflow. Skills are where a team's working knowledge lives: the prompts, conventions, and procedures you want every agent session to follow. The **skills library** is your workspace's shared catalog of skills. From the Skills page (on the web or in the desktop app) you can publish a skill from your machine to the library or install a team skill locally. Threads also record which skills a session invoked, so you can see how a skill performs in real work. # Components Lore is made up of a few components: - A **macOS desktop app** that browses Lore in its own window, captures your coding-agent sessions in the background, and installs the plugin into your agents automatically. - A **plugin** for Claude Code and Cowork that lets you share and read threads without leaving your session. - A **web service** for browsing your threads, managing sharing permissions, and hosting your team's **skills library**. You don't need to install the plugin yourself; the desktop app sets it up. # Harnesses A **harness** is the coding agent a session came from. Lore recognizes Claude Code, Cowork, and Amp, plus threads created directly in the Lore web UI. (Cowork sessions come from Cowork running inside Claude Desktop.) The harness is attributed at upload time so threads can be filtered and analyzed per agent. # Workspaces A **workspace** is your team in Lore, keyed by a verified email domain. Workspace IDs start with `org_`. Anyone who signs up with the same company email domain is automatically added to the same workspace, with no manual invitations, and `workspace`-visibility threads are shared across everyone on the domain. You can belong to more than one workspace and switch between them in the web UI. Public email domains (gmail.com, outlook.com, and the like) are excluded from auto-grouping, so personal-email signups don't get pooled into a shared workspace. See [Data Privacy](/docs/data-privacy#article-data-privacy) for how workspace membership drives default visibility. --- ## Using Lore: Sharing Sessions 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 deterministically indexes each shared session, so you can filter and search through it (and your team's shared sessions) much faster than if you asked your agent to search through sessions on your own computer. # Share with the plugin Type `/lore:share` inside any Claude Code or Cowork session with the [Lore plugin installed](/docs/overview#install-lore). 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. Lore uploads a session only when you run the share command. # Controlling Visibility 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`. Change a thread's visibility afterwards from its Share menu. See [Data Privacy](/docs/data-privacy#article-data-privacy) for a full explanation of the three visibility levels. --- ## Using Lore: Reading Threads Lore threads are searchable and retrievable from inside your coding agent or from the web. # Using the Plugin If you installed the plugin, type `/lore:read` inside Claude Code or Cowork to fetch or search threads. You can: - Paste a thread ID (`th_...`) or a Lore URL to fetch a specific thread - Ask for recent threads from your workspace - Filter by author, file path, or time range The agent retrieves thread content from Lore and summarizes it inline. # Browsing the Web UI Visit [lore.link](https://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. --- ## Using Lore: Searching Threads Use quick search to find threads, skills, and people in Lore. # Quick search Press `/` anywhere in the web app (or click the search box) and start typing. Quick search matches as you type across three kinds of results: - **Threads by title**. This is a literal title match, so it's the right tool when you remember roughly what a thread was called. - **Skills**, ranked by how many threads have invoked them. - **People** in your workspace, by name or handle. Quick search only ever shows you threads you're allowed to see. # Chatting with your threads Existing Lore threads support follow-up questions with context. Answers stream with citations and record their search steps in the transcript, so you can see what was searched and why. 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. # Filter the thread feed The threads feed has filters for narrowing by **author** and, for threads uploaded via the API, **upload key** and **metadata**. Filters combine, so you can use more than one constraint together. # From the plugin Inside your coding agent, `/lore:read` fetches a thread by ID or URL, lists recent workspace threads, and searches threads by title keywords. --- ## Using Lore: 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 with the `/lore:fork` command shown below. # Using /lore:fork in your agent ``` /lore:fork ``` For example: ``` /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. # How It Differs From Reading Threads - **`/lore:read`** fetches thread content for inspection. This is useful for understanding what happened, reviewing decisions, or referencing prior work. - **`/lore:fork`** 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. # Why the Intent Matters 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. # Example Use Cases - **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 --- ## Using Lore: 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. # The Skills page The Skills page at [lore.link/skills](https://lore.link/skills) has three tabs: - **Your Skills** shows your personal skills. This tab needs the [desktop app](/docs/overview#install-lore) (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. # Share or publish a skill 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 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 a team skill Install from the **Team Skills** tab in the desktop app. The skill is written to `~/.claude/skills//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. # Stay in sync The desktop app keeps skills in sync: - 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 publish again. # Propose and review changes 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. Versions are timestamps rather than semver, the full history is kept, and re-publishing identical content is deduplicated instead of creating a noise version. # Share a skill outside your workspace 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. # Skills in Workbench Skills also work inside [Workbench sessions](/docs/using-workbench#article-workbench-skills): enable a skill from the session composer's **+** menu or with the **Use in Workbench** toggle on a skill's detail pane, and the agent activates it when it's relevant. Owners see how many recent Workbench turns used each of their skills on the skill's detail pane. # Skills on threads 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](/docs/using-lore#article-searching-threads) can also filter by skill. # Notes - 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. --- ## Using Lore: Account Settings Your account-level settings live on the web at [lore.link](https://lore.link), under **Settings → Account**. This page is where the "account sharing preference" referenced throughout these docs actually lives. # Share new threads with my workspace 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 the desktop app, the plugin's `/lore:share`, and the MCP `share_session` tool. See [Data Privacy](/docs/data-privacy#article-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. # Email to Workbench You can let more than one email address start private Workbench sessions for your Lore account: 1. Under **Email to Workbench**, add the address that you want to use. 2. From that address, send an email to the Lore inbox shown in the setting. 3. Return to account settings and select **Refresh**. The address changes from **Pending verification** to **Active** after Lore authenticates the message. The verification email activates the address but does not start a session. Later authenticated emails from that address can start sessions. Your primary account email stays active. You can remove an additional address at any time. # Other account settings The same page also lets you: - **Experimental features:** opt your account into in-progress features before they roll out more broadly. - **Billing:** jump to your plan and subscription management. # Changing a single thread's visibility You don't have to change the default to adjust one thread. Open any thread at [lore.link](https://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. --- ## Using Lore: Troubleshooting Common issues and how to resolve them. # My session was not shared Lore shares sessions on demand. Run `/lore:share` in Claude Code or Cowork, `$lore:share` in Codex, or **Lore: Share active Amp thread** in Amp. If the command fails, check that the plugin is installed and signed in, then retry. # I keep getting logged out Access tokens are short-lived and refreshed automatically. If your desktop session expires, sign in again from the app. If the plugin session expires, use its login flow again. # The plugin won't authenticate 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. # My teammates aren't showing up in my workspace 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. # "Thread not found" 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. # Did re-sharing create a duplicate? No. Lore deduplicates by session, so sharing the same session again returns the existing thread instead of creating a copy. Re-sharing is safe. # I can't reach the API Network errors like `ECONNREFUSED` or `ENOTFOUND` mean the app or plugin couldn't reach Lore's API. Check your connection and any corporate proxy or firewall, then retry. --- ## Using Workbench: Workbench Basics **Workbench** is Lore's agent for real work on your Mac. Each Workbench session is a chat window bound to a folder on your computer: you describe the work, and the agent reads and edits files, runs commands, browses the web, and produces documents, using your team's knowledge in Lore as it goes. Every session becomes a Lore thread automatically, so the work is shared, searchable, and forkable like everything else in your library. Workbench is part of the [Lore desktop app](/docs/overview#install-lore) (macOS). You sign in with your Lore account; there are no API keys to configure and no model settings to manage. The agent itself runs on Lore's servers against your signed-in session, while your Mac executes the file, command, and browser actions. # The sidebar Workbench lives in a slim sidebar that snaps to the left or right edge of your screen. Hover it to expand it. - **Recent** shows your recent Lore threads and local Workbench drafts. - A working status shows which threads still have active work. - **Click** a thread to open or return to its Workbench session. - **New thread** opens a composer for starting work without leaving the sidebar. Each active session opens in its own native window. In a session, you can mention Lore threads, use Workbench skills, and open artifacts produced by the work. # Keyboard shortcuts | Shortcut | Action | | -------- | ---------------------------------- | | `⌘⌥T` | Show or hide the Workbench sidebar | The same action lives in the menu bar icon, along with **Open Lore** and **Start at Login**. # Signing in Workbench requires a signed-in Lore account. Signed out, sessions refuse prompts with "Sign in to Lore to use the Dock.", and skills and document editing are unavailable until you sign in again. Turns are metered against your team's Lore plan; if a turn stops with "Ran out of budget", that is the meter, not an error on your machine. --- ## Using Workbench: Running Sessions A session is a conversation with an agent that acts in its folder. Type what needs to be done and press Enter (Shift+Enter for a new line). While the agent works you'll see its progress ("Thinking…", "Responding…"), each action it takes as an activity chip, and a settled outcome when the turn ends. The composer stays typeable during a turn, so you can draft the next request while the current one runs; **Stop** cancels a turn you no longer want. # What the agent can do Inside the session's folder, the agent can: - **Read, write, edit, and delete files.** Deletions are real deletions, so give sessions a folder you mean them to work in. - **Run shell commands**, with a 60-second limit per command. - **Browse the web** in a browser it opens on your Mac: navigating, reading pages, clicking, typing, and taking screenshots it can look at. - **Show its work**: reports, briefs, and documents open in the [artifact pane](/docs/using-workbench#article-artifacts). It also reaches your team's knowledge in Lore: searching threads, attaching them as [sources](/docs/using-workbench#article-session-sources), using [skills](/docs/using-workbench#article-workbench-skills), and reading [connected tools](/docs/using-workbench#article-connectors). The agent acts without confirmation prompts. You direct it by what you ask, which folder you give it, and the Stop button; the one hard brake is that a document you are actively editing is locked against agent writes until you're done. # Mention threads with @ Type `@` in the composer to search your Lore threads and mention one. Mentioned threads are attached to the session as sources before the turn runs, so the agent reads them as context. Deleting the `@Title` from your draft un-mentions it. # How turns end Every turn settles with an honest outcome line: - **Done**: the work completed and its file changes were verified. - **Finished**: completed, but not independently verified. - **Partially done**: some of the work landed. - **Stopped**: you cancelled it. - **Ran out of budget**: the turn hit your team's usage meter. - **Something went wrong. Try again in a moment.** - **Unconfirmed — needs review**: the session ended in a state Lore could not confirm, with a reference you can quote when asking about it. A quieter second line notes what happened to your files when that needs saying, and which set-aside sources were left out of the request. # Citations in answers When an answer draws on your sources, it carries small numbered markers. Click one to open the source it cites: a bound document, a Lore thread at the exact block, or an output file. A trailing **i** marker opens a summary of what was left out of context and why (sources set aside, earlier reads dropped, restricted material), so you can tell what the answer did not see. # Keeping the app current If a "Update Lore to restore file and command tools." notice appears above the composer, the desktop app has fallen behind the server and its local tools are paused. Use the **Check for Updates** button on the notice, then retry. --- ## Using Workbench: Workbench Skills Your team's [skills](/docs/using-lore#article-skills) work inside Workbench sessions. Enabling a skill adds it to the agent's catalog; the agent applies a skill's instructions only when it activates that skill for the task at hand, so enabled skills stay inert until they're actually relevant and asked for. # Enable skills from the composer The **+** button in the composer opens a menu with **Use skills**: one checkbox per skill you can see, checked when it's enabled for your Workbench. Toggling here and toggling **Use in Workbench** on the [Skills page](https://lore.link/skills) write the same setting, so the two stay in step. **Manage skills…** in the same menu opens the Skills page. Enabling pins the skill's current accepted version for you. If the owner publishes a new version later, your Workbench keeps using the pinned one until you enable the skill again. Some shared skills are templates with inputs you have to fill in first. Enabling one of those before resolving its template is refused with the reason; resolve the template on the Skills page, then enable it. # While a skill is in use When enabled skills are active in a session, a caption above the composer names them, so you always know what standing instructions the agent is working under. Skill instructions can guide the agent, but they cannot grant it tools or permissions it doesn't already have. # See whether a skill earns its keep If you own a skill, its detail pane on the Skills page shows "Used in N recent Workbench turns": how many turns actually activated it recently. A skill nobody's Workbench ever activates is a candidate for a better description, or retirement. --- ## Using Workbench: Attaching Files # Attaching files Attach images and files to the next message in a Workbench session. Drop a file on the composer, paste an image, or use the attachment picker. The desktop composer also has a paperclip button. Attachments are shown as chips with their name and size before you send the message. Supported types are PNG, JPEG, WebP, GIF, PDF, plain text, Markdown, and CSV. You can attach up to 4 images and 4 files to one message. Images share a 5 MB per-message limit. Files share a 10 MB per-message limit, and each text file is limited to 1 MB. PDFs are limited to 100 pages. SVG, Word, Excel, and other unsupported formats are rejected. Attachments are uploaded before the message is sent. The message stores only a descriptor for each attachment; it does not store file bytes. The bytes are kept in the private attachment storage used by Lore. Existing attachments remain readable. ## What the model receives - Claude and GPT can receive a PDF as a native document on the turn where it is attached. If the document is too large for the model step, Lore uses its extracted text instead. - Grok receives extracted PDF text. Later turns use extracted text for every provider, so you can ask follow-up questions without sending the PDF again. - Text, Markdown, and CSV attachments are sent as wrapped text on every turn. - GIF attachments use the first frame. Lore extracts PDF text once when the file is uploaded. If extraction is not available, the model receives a short placeholder naming the file. Figures and other visual details in a PDF are available on the native-PDF turn only; attach the PDF again when a later question needs its visuals. ## Access and previews Each chip links to a preview or download URL. PDF previews open inline when the browser supports them. Anyone who can read the thread can read its attachment, including an anonymous viewer of a public thread. The same thread visibility rules apply to attachment reads and no separate public attachment permission is created. --- ## Using Workbench: Session Sources Session sources are the working material the agent can draw on: reference documents you [uploaded](/docs/using-workbench#article-attaching-files), Lore threads bound by [@-mention](/docs/using-workbench#article-running-sessions) or attached by the agent itself, and artifacts registered from earlier work. Threads are bound as point-in-time snapshots, so the agent reads what the thread said when it was attached. # What the agent saw Citation markers in answers link to the exact document, output, or Lore thread used for that part of the response. Select a citation to preview its source in the side pane. Restricted or unavailable sources remain marked without exposing their contents. The agent can set a source aside when it stops being relevant. Setting a source aside changes the session context but does not change the original document or thread. --- ## Using Workbench: Artifacts When the agent produces something worth looking at, it opens in the **artifact pane** beside the chat: self-contained HTML pages, Markdown, plain text, and images all render in place. The pane resizes by dragging its edge, and **Focus** gives the document the whole window when you're reading rather than chatting (**Collapse** brings the chat back). # Publish an artifact **Publish** uploads the shown file to the session's Lore thread and copies a web link to your clipboard ("Link copied"). That's the fastest path from "the agent made this" to "there's a link for this". Who can open the link is a separate question, answered by visibility. An artifact is always visible to everyone who can see its thread — sharing the thread always shares the artifact. On top of that, the artifact's author can publish it wider from the web app's Artifacts page: **Share → Publish to workspace** makes the artifact itself workspace-visible even when its thread is private. Publishing only ever widens the audience; making the artifact private again returns it to exactly the thread's audience. # The outputs list **Outputs** below the session toolbar lists every file the session has produced. Each row offers: - **Save a copy…** to write the file wherever you choose. - **Revise** to seed the composer with a revision request for that file. - **Remove from outputs** (and later restore) to curate the list without deleting anything. # Edit documents while the agent works Documents the agent writes in Lore's document format open as an editable page, not a static preview. You can edit inline, even mid-turn: a save chip tracks "Saving…" / "Saved", and while you hold an edit the agent's writes to that file are refused, so your changes can't be clobbered. If your copy and the agent's diverge, the editor keeps "your unsaved text, so you can put it back". # Work with claims In research briefs the agent produces, individual claims are selectable. Select one and **Fan out** expands it in place into its constituent evidence; select two and **Compare** inserts a side-by-side comparison, both preserving the original source ties. --- ## Using Workbench: Forking Sessions A session sometimes wants to go two directions at once: keep the main thread of work moving, and chase a side question with all the same context. Forking copies the session's history into a new session so both can proceed independently. Forked sessions are ordinary Lore threads, so the family is visible in your library too. # Ways to fork - The **Fork** button in the session titlebar forks into a new window beside the current one. - Type **`/btw`** in the composer to fork in place: this window swaps to the fork, and the original keeps its state. Add a message (`/btw check whether the API also needs this`) and it's sent as the fork's first turn. Forking waits for a quiet moment: a session mid-turn asks you to fork once the turn finishes, and a session with no messages yet has nothing to fork. # Finding your way around a family A forked session shows a **↩ parent** breadcrumb; click it to swap back. The **Forks** control lists the whole family with an excerpt of each, and clicking a member swaps this window to it, so one window can walk the whole tree. --- ## Using Workbench: Connectors Connectors let the agent read from tools your team already uses, on demand, inside your own sessions. Nothing is indexed or copied into Lore ahead of time: when a turn needs something from a connected tool, the agent fetches it then and there. Four connectors are available today, all in preview: - **Notion**: search and read pages the connected account can see. - **Granola**: search meetings, read notes, and pull transcripts. - **Google Docs & Sheets**: search and read the documents and spreadsheets you pick. - **Linear**: list and filter issues, read one issue, and read its comment thread. All of them read. None of them write: no connector can create a page, post a message, or file an issue. # Connect an account Open the **Connectors** page in Lore. Each row shows the connection's workspace, when it was connected, and when a session last used it, with **Connect**, **Reconnect**, and **Disconnect** controls. Access grants expire eventually; a "Reconnect needed" badge and a reconnect prompt appear when that happens. # Pick the Google files Lore can read Notion, Granola, and Linear are scoped by account: the connector sees what the connected account sees. Google is scoped by file instead. Connecting the account grants nothing on its own, and you choose the files one at a time. A connected Google row shows a **Select files** button that opens Google's own file picker. The files you pick there are the only ones Lore can ever read, and the button carries the count once you have picked some. The row's status line repeats the rule: "Lore can only read the files you select." The picker offers both Google Docs and Google Sheets. Picking again adds to the list instead of replacing it, and picking the same file twice changes nothing. Reconnecting the same Google account keeps the list; connecting a different account clears it, and disconnecting drops it with the connection. In a session, the Google tools stay inside that list. Search matches file titles only, across your selected files, so it never becomes a search of the rest of your Drive; it also tells the agent whether each result is a document or a spreadsheet. Fetch returns one selected document as Markdown. A request for a file you never picked is refused with the reason, not answered with an empty result. Spreadsheets take two steps, because a spreadsheet's tab names cannot be known from the file alone. The agent first asks for the sheet and gets back its tab names and sizes, then asks again for one tab and gets that tab's cells. Reading a very tall tab returns the first rows and says plainly that it truncated, so the agent never treats a prefix as the whole sheet. # Reading from Linear Listing issues filters by any combination of assignee, status, team, project, label, and cycle, so "what is assigned to me" and "what is in this cycle" both work. A free-text query is available on top of those filters but is left off for a plain listing, because adding one narrows the result to text matches and a short list is easy to mistake for a complete answer. Fetching one issue returns its full description and metadata. The third tool reads an issue's comment thread, which is usually where a decision's reasoning lives when the description alone does not explain it. The connector requests read access only, so a session can find and read your Linear work but cannot create, edit, or move anything. # Reading from Slack Search covers messages in public channels. Slack's search permission is broader than that on Slack's side, so Lore filters the results: anything from a private channel or a direct message is discarded before the agent sees it, even when the connected account could read it. Reading a channel or a thread is limited to public channels by the granted permissions themselves. Message authors arrive as Slack ids rather than names, so there is a fourth tool that turns an id into a person. As with every other connector, nothing here writes: the agent cannot post a message or reply on your behalf. # How sessions use connections Connections are personal: a session offers connector tools only when the thread's author (you, for your sessions) holds a live connection. They're also held back on public threads, since anything a connector fetches lands in the transcript, and a public transcript is visible to anyone with the link. Private and workspace-visible threads get the tools as normal. When a connected tool can't be reached or needs re-authorization, the agent is told exactly that rather than seeing an empty result, so it will tell you to reconnect instead of confidently reporting that your document doesn't exist. --- ## Data Privacy: Data Privacy Lore gives you control over who can see each thread that you choose to share. # Thread Visibility Every thread has one of three visibility settings: - **`private`** is visible only to you. - **`workspace`** is visible to anyone on your team (matched by email domain). - **`public`** is visible to anyone with the URL, including people outside your workspace. New threads get their visibility from your **Share new threads with my workspace** setting (Settings → Account), which is **on by default**. The effective default is: - **`workspace`** if you belong to a workspace and the setting is on. - **`private`** if you're not in a workspace, or you've turned the setting off. You can update a thread's visibility after the fact from the web UI at [lore.link](https://lore.link). # What gets uploaded When you share a session, Lore uploads the session transcript and its metadata: - **The transcript as your agent recorded it**: your prompts, the assistant's responses, tool calls and their results, and thinking and planning blocks. Tool results can include file contents the agent read and command output it saw, so assume the transcript contains everything the agent itself saw during the session. - **Session metadata**: the working directory, repository origin, file paths touched, skills and slash commands invoked, and timestamps. Lore doesn't scan or collect anything else from your machine. If something wasn't part of the agent session, it isn't uploaded. Every upload path runs a local secret scan before anything leaves your machine. The detection ruleset (derived from gitleaks) ships inside the desktop app and SDK and runs entirely offline. - Sessions with no findings upload as-is. - Findings that can be safely redacted are replaced in the uploaded copy. - Anything the scanner can't confidently redact **quarantines the whole session**: it stays on your machine and is never uploaded. The scan fails closed, so a session that can't be parsed or scanned is quarantined too. # Deleting data You can delete any thread you authored, from its menu in the web UI or via the API. Deletion takes effect immediately across every surface: feeds, search, ask, share links, and the API all stop returning the thread. Deletion in this manner makes the thread inaccessible to anyone in your workspace, although it remains tombstoned in our database. You can also permanently delete all your account data (including deletion from our database and object storage) through the "Delete my threads and uploaded data" button at the bottom of your [account settings](/account/settings). # Storage and authentication - Parsed threads and metadata live in a managed Postgres database; raw transcript files live in S3-compatible object storage. Data is encrypted in transit. - Sign-in uses OAuth via WorkOS across the web app, desktop app, and plugin. Clients hold short-lived access tokens with refresh tokens, and a failed refresh signs the client out rather than retrying forever. - Local credentials and state (`~/.lore`) are written with owner-only file permissions. For the formal policy, see the [privacy policy](https://lore.link/privacy). For security questions we haven't answered here, [email founders@lore.link](mailto:founders@lore.link).