Using Lore

Setup

The easiest way to use Lore is the macOS desktop app: it browses Lore in its own window, captures your sessions in the background, and installs the Lore plugin into your coding agents automatically. There's nothing else to install. The plugin and the CLI can also be set up on their own (if you're not on macOS, or you want a scriptable interface); the options below cover those too.

Option 1: Install the desktop app (macOS)

Recommended

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 and captures your coding-agent sessions in the background.

Download the macOS app

Download it from lore.link/desktop and drag Lore into Applications.
Sign in through your system browser.
Approve the Claude Code connection; the app shows you the exact settings it will add before writing anything.

That's it. The app keeps itself up to date, starts capturing sessions in the background, and installs the Lore plugin into your coding agents (Claude Code, Cowork, Claude Desktop, and Amp) automatically, so you never have to set up the plugin or the CLI yourself. The usual upload filters and visibility rules apply (see Privacy and Visibility). For everything the app can do, see Desktop App.

Option 2: Install the Plugin

Using the desktop app? Skip this section; the app installs the plugin for you. The manual steps below are for anyone setting up the plugin without the desktop app.

The Lore plugin works with Claude Code and Cowork (in Claude Desktop). Pick the instructions for your agent below.

Open Customize from the side bar.
Click +, then choose Create (not Browse).
Click Add marketplace, enter tanagram/lore-plugin, and click Sync.
Under the Personal tab (next to “Anthropic & partners”), open the Tanagram marketplace and install the Lore plugin.

Inside a live Claude Code session, run /plugins to open the interactive plugins TUI.
Switch to the Marketplaces tab and choose Add Marketplace.
Enter the marketplace source: tanagram/lore-plugin.
Open the new tanagram (or Tanagram) marketplace and install the Lore plugin.

Claude Code: /plugins → Marketplaces → tanagram → install Lore:

Claude Code marketplaces list with the tanagram marketplace highlighted

Claude Code tanagram marketplace showing the Lore plugin installed

Or install from a plain terminal outside a session:

claude plugin marketplace add tanagram/lore-plugin
claude plugin install lore@tanagram

This gives you the plugin slash commands: /lore:share to export sessions, /lore:read to read and search threads, and /lore:fork to continue from an existing thread. Background session capture is managed by the desktop app or the CLI (lore configure), not by a plugin command.

The plugin bundles Lore's MCP server, so the slash commands and the Lore MCP tools are both available the moment it's installed. You don't need to add the MCP server separately; that's only for clients that aren't using the plugin (see MCP Server).

The first time you use the plugin, it will walk you through authenticating with your Lore account.

Option 3: Install the CLI

The CLI is optional; if you use the desktop app, background capture is already built in. Install the CLI for lore threads fork (continuing work from existing threads), a scriptable interface to Lore's APIs, or background uploads on a machine without the desktop app.

npm install -g @loredotlink/cli
lore login

The login flow prints a verification URL and a short user code. Open the URL in your browser, enter the code, and you're authenticated. On macOS, lore login also enables the background uploader (it only uploads what your filters allow; see below). The CLI gives you the lore command set (lore export, lore threads ..., and more); the slash commands come from the plugin.

Background Uploads (CLI)

On macOS, lore login enables the background daemon automatically, and the first run walks you through picking directories to watch. You can revisit that configuration any time:

lore configure                         # interactive directory picker
lore enable                            # start the background daemon
lore disable                           # stop the background daemon
lore status                            # verify it's running

You can also manage watched directories directly:

lore listen create ~/projects/my-app   # start watching a path
lore listen list                       # show all watched paths
lore listen delete ~/projects/my-app   # stop watching a path

The daemon runs as a macOS LaunchAgent and uploads sessions as they are created or updated, subject to the filters in ~/.lore/upload_filters.json (an empty allowlist uploads nothing). You can always share individual sessions on demand with /lore:share or lore export.

Desktop App

The Lore desktop app is a native macOS app that does two jobs: it browses Lore in its own window, and it captures your coding-agent sessions in the background, with no terminal involved. It also installs the Lore plugin into your AI tools automatically, so the app is the only thing you install; the plugin and CLI never need to be set up by hand.

Install

Download the app from lore.link/desktop.
Open the .dmg and drag Lore into Applications.

The app is signed and notarized, so macOS opens it without warnings. It requires an Apple Silicon Mac.

Once installed, the app keeps itself up to date: it checks for new versions on launch and every few hours, downloads updates in the background, and installs them when you restart or quit. You can also update on demand with Check for Updates in the app menu.

First run

Setup is two steps:

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.
Approve the Claude Code connection. Lore captures Claude Code sessions through Claude Code's own telemetry support, which requires a few lines in ~/.claude/settings.json. Before writing anything, the app shows you the exact lines it will add, and nothing is written until you click Allow. If you'd rather edit the file yourself, choose Set up manually and the app gives you a snippet to paste.

If you've used the app before, you won't see these steps again; the app opens straight into Lore.

You can undo the Claude Code connection at any time with Disconnect Claude Code Telemetry in the app menu. It removes exactly the lines it added and leaves the rest of your settings untouched. If something else edits ~/.claude/settings.json and breaks the connection, the app notices on launch and offers to repair it.

Background capture

After setup, the app uploads your Claude Code and Cowork sessions as you work. A status pill in the title bar shows what it's doing: Importing sessions while uploads run, Waiting for activity when it's idle, and states like Consent needed or Signed out when it needs your attention.

A few things worth knowing:

What gets captured. By default the app captures sessions from projects anywhere in your home directory. If you've set up upload filters with the CLI (lore configure, or the filters in ~/.lore/upload_filters.json), the app respects them.
Visibility. Uploads follow the same visibility rules as every other way of sharing: your default visibility setting applies, and you can change any thread afterwards. See Privacy and Visibility.
Nothing else to install. Background capture is built into the app; you don't need the CLI or the plugin for it. If you happen to run the CLI's background daemon too, the two coordinate so only one uploads at a time; nothing is uploaded twice.

When the app is capturing in the background, the Lore web app shows an Active indicator in the header, so teammates browsing on the web can see the desktop app is doing the uploading for you.

Connect your AI tools

The app detects which agents you have installed (Claude Code, Cowork, and Amp) and installs the Lore plugin into each for you, using your existing desktop sign-in. You never install the plugin by hand: no marketplace steps, no copying tokens, no install commands. You can re-run detection any time from Connect AI Tools in the app menu. For Cowork, the app walks you through enabling the plugin from Cowork's own settings.

Skills

When you browse Lore inside the desktop app, the Skills page can also see the skills on your machine: it scans your local skill folders (like ~/.claude/skills) and lets you publish a local skill to your team's catalog, or install a team skill locally, directly from the page. See Skills for the full workflow.

Troubleshooting

Sign-in finished in the browser, but the app didn't notice. Make sure the browser prompt to open "Lore" was accepted; macOS asks the first time. Then try signing in again.
The status pill says Import error or Import stale. Quit and reopen the app. If it persists, choose Open Logs from the Help menu; the app logs to ~/.lore/desktop.log.txt.
Sessions aren't showing up. Check your upload filters (lore listen list, if you use the CLI) and see Troubleshooting for the general checklist.

Sharing Sessions

Sharing a session takes a single command inside your coding agent.

Share with the plugin

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 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.

Share from the CLI

If you have the CLI installed, share the current session with 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

These explicit shares always run, bypassing the background daemon's upload filters.

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. 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 Privacy and Visibility for a full explanation of the three visibility levels.

Background Uploads vs On-Demand Sharing

There are two ways sessions end up in Lore:

Background daemon (CLI only, lore enable): automatically uploads sessions from your configured directories as you work, subject to your upload filters.
On-demand share (/lore:share in the plugin, or lore export from the CLI): exports and shares a specific session right now.

Both paths apply the same default visibility from your Share new threads with my workspace setting (workspace when you're in a workspace and the setting is on, otherwise private). The daemon ensures your sessions are preserved; on-demand sharing is for when you want to hand a link to someone immediately. Either way, you can change any thread's visibility later from its Share menu at lore.link.

Reading Threads

Lore threads are searchable and retrievable from inside your coding agent, from the web, or from the command line.

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.

If you use the CLI instead of the plugin, the lore threads commands below cover the same fetching and searching.

Browsing the Web UI

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.

CLI Commands

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.

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.

Ask your threads

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.

Good ask queries look like:

"what have we decided about rate limiting?"
"who worked on the billing migration last month?"
"threads that touched apps/api/src/search"

Chatting with your threads

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.

Filter the thread feed

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.

Similar threads

Every thread page shows a Similar Threads card once the thread's summary is ready, listing the closest related threads by content similarity. It's the fastest way to find prior art on whatever a thread is doing.

From the CLI and plugin

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).

Using /lore:fork in your agent

/lore:fork <thread-url-or-id> <intent>

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 (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.

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

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 has three tabs:

Your Skills shows the skills on your machine. 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. You can filter to skills you wrote, skills you've shared, and skills installed from your team, and each skill's detail pane is where you publish, unpublish, and manage visibility.
Team Skills is your workspace's shared catalog. Each skill shows its owner, latest version, and how many threads have invoked it. In the desktop app you can install a skill straight from here; 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.

Publish a skill

You can share a personal skill with your team from the skill's detail pane on the Your Skills tab, whether you're on the Skills page in the desktop app or at lore.link/skills in your browser, or from the CLI:

lore skills publish <name>

Publishing puts the skill in your workspace's Team Skills catalog. You stay the owner: only you can push updates directly, change its visibility, or unpublish it. Publishing 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, 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.

Stay in sync

lore skills sync

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.

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. 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.

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 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 can also filter by skill.

Notes

Cowork skills are visible on the Your Skills tab but read-only: Lore 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.

Privacy And Visibility

Lore gives you control over who can see your threads, both at the individual thread level and through upload filters for the CLI's background daemon.

Visibility Levels

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.

The Default Visibility

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.

This rule is applied identically by every upload path: the background daemon, lore export, the plugin's /lore:share, and the MCP share_session tool.

Changing Visibility When Sharing

You can override the default for a single share from the CLI with --visibility (plugin shares always use your default; adjust them afterwards from the thread's Share menu):

lore export --visibility private     # only you
lore export --visibility workspace   # your team
lore export --visibility public      # anyone with the URL

You can update a thread's visibility after the fact from the web UI at lore.link.

Controlling What the Daemon Uploads (CLI)

If you use the CLI's background daemon (lore enable), it respects upload filters defined in ~/.lore/upload_filters.json. This lets you restrict which sessions are automatically collected.

{
  "include": {
    "cwd": ["/Users/alice/projects/work"],
    "repo": ["github.com/myorg/myrepo"]
  },
  "exclude": {
    "cwd": ["/Users/alice/projects/personal"]
  }
}

Filter logic:

cwd and repo are a union. A session is location-allowed if it matches a cwd rule OR a repo rule, so you can allowlist a git repo and a standalone directory at the same time (a non-git directory uploads via its cwd).
When set, skills further narrows that set (ANDed). The session must also match a skills rule.
Within a dimension, multiple values are ORed. Matching any one value is sufficient.
exclude rules override includes. A session matching an exclude rule is never uploaded regardless of includes.

If include is empty or omitted, no sessions are uploaded. Explicit shares (lore export, lore share-cowork) bypass these filters entirely.

Managing Watched Directories (CLI)

Use these commands to control which directories the daemon watches:

lore listen create ~/projects/work   # start watching
lore listen list                     # show all watched paths
lore listen delete ~/projects/work   # stop watching

See Setup for initial configuration.

Editing and Redacting Threads

You can clean up a thread after it's uploaded. Hover any of your own prompt or assistant text in the transcript and click the Edit button to make changes. Two operations are available, and both are author-only:

Edit text rewrites the passage in place. Edits are recorded: anyone who can view the thread can open the block's edit history and see what changed, so use editing for fixes, not for hiding content.
Redact selection permanently destroys the selected characters, replacing them with block characters (█). Redaction asks for confirmation and cannot be undone.

Editing covers your prompts, the assistant's replies, and thinking text. Tool calls and tool results can't be edited; if a whole thread shouldn't be up, delete it instead. And if a real secret reached a shared thread, treat it as exposed and rotate it; redaction cleans the record, it doesn't un-ring the bell.

Workspace Auto-Grouping

Users who sign up with the same email domain are automatically added to the same workspace. There is no manual invitation step; your teammates can sign up independently and they'll see workspace-visibility threads from anyone on the domain.

Security

This page explains what Lore collects, how uploads are protected, who can see what, and how deletion works. For the mechanics of visibility settings and upload filters, see Privacy and Visibility.

What gets uploaded

When a session is captured or shared, 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.

Secrets are scrubbed before upload

Every upload path runs a local secret scan before anything leaves your machine. The detection ruleset (derived from gitleaks) ships inside the CLI and desktop app 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.

You can review and manage held sessions with lore quarantine list, lore quarantine show, lore quarantine release, and lore quarantine discard.

You decide what gets captured

The desktop app captures nothing until you explicitly grant consent during setup. After consent, it captures sessions from projects in your home directory by default; narrow that with upload filters.
The CLI background daemon is allowlist-based. With an empty allowlist it uploads nothing; you opt directories and repos in with lore listen and the filters in ~/.lore/upload_filters.json. exclude rules always win over includes.
Explicit shares (/lore:share, lore export) upload exactly the session you asked to share. They bypass directory filters but still go through the secret scrubber.

Who can see a thread

Access control is enforced server-side: every thread read, whether it comes from the web app, the API, the CLI, or MCP, is checked against the viewer's permissions at the database query level. There is no client-side-only gating.

private threads are visible only to their author.
workspace threads are visible to members of your workspace.
public threads are visible to anyone with the URL. Signed-out visitors can only ever see public threads.

Workspace membership follows your email domain: anyone who signs in with an email address at your company's domain joins the workspace automatically, and public email providers (gmail.com and the like) are excluded from this grouping. That means workspace visibility extends exactly as far as your email domain does; if contractors or shared mailboxes use your domain, they can see workspace threads too.

Note that new threads default to workspace visibility when you belong to a workspace (controlled by the Share new threads with my workspace setting, on by default). See Privacy and Visibility.

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 removes the thread from the product immediately; permanent removal from underlying storage is completed through our administrative process. Account deletion is handled on request; see the privacy policy for the formal commitments.

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, CLI, 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. Security questions we haven't answered here: contact us.

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.

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 every upload path (the background daemon, lore export, the plugin's /lore:share, and the MCP share_session tool). See Privacy and Visibility 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.

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.
Replay onboarding: see the first-run onboarding again.

Changing a single thread's visibility

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.

Troubleshooting

Common issues and how to resolve them.

My sessions aren't uploading

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 nothing. Run lore configure to pick directories, or add cwd/repo rules. See Privacy and Visibility.
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.

Background uploads on Linux or Windows

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.

I keep getting logged out

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 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.

"Unsupported Node version" when installing the CLI

The CLI requires Node 20 or newer. Upgrade Node, then re-run npm install -g @loredotlink/cli.

I can't reach the API

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.