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.

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

Upload Filters#

The macOS app and CLI share upload filters at ~/.lore/upload-filters.json. The app's Configure Session Upload… screen and CLI commands such as lore configure write the same file, so a change on either surface applies to both.

{
  "version": 2,
  "include": {
    "cwd": ["/Users/alice/projects/work"],
    "repo": ["myorg/myrepo"],
    "skills": []
  },
  "exclude": {
    "cwd": ["/Users/alice/projects/personal"],
    "repo": [],
    "skills": []
  },
  "coworkUploadEnabled": true,
  "codexUploadEnabled": true
}

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 also ORed. Matching any one value is sufficient.
exclude rules override includes. A session matching an exclude rule is never uploaded regardless of includes.
The cwd/repo/skills rules apply to Claude Code. Cowork and Codex are folder-independent and use coworkUploadEnabled and codexUploadEnabled; either setting defaults to enabled when omitted.

For the CLI daemon, a missing file or an empty include set uploads no Claude Code sessions. On a true first run with no file, the macOS app starts with an explicit "cwd": ["*"] default; saving settings writes that choice to the shared file. A present but malformed file fails closed instead of enabling the wildcard. Explicit shares (/lore:share in the plugin or lore export in the CLI) bypass these filters entirely.

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.

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 in the CLI.

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.

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. For security questions we haven't answered here, email [email protected].