@lore-co/cli

v0.2.17

Published

4 hours ago

Connect Claude Code, Codex, Cursor, OpenCode, Polytoken, and T3 Code to Lore shared engineering memory

0High
0Medium
0Low

obbadmin

lore codex claude cursor opencode polytoken t3code memory ai

Lore CLI

The Lore connector installs native Codex, Claude Code, Cursor, and Polytoken lifecycle hooks plus the Lore OpenCode plugin. For each supported prompt, Lore attempts to retrieve relevant engineering context. A first prompt is observed on its own; later prompts are paired with the previous assistant response when valid pending state is available. Capture, context retrieval, and response staging failures fail open so they do not block the agent. Guard is the exception: known Enforce fails closed for Guard-eligible actions, as described below.

Install and connect

pnpm install --global @lore-co/cli

lore connect \
  --folder . \
  --login \
  --agent claude \
  --agent codex \
  --agent cursor \
  --agent opencode \
  --agent polytoken

lore doctor

The package requires Node.js 22 or newer and installs the lore command.

In Connect, This project asks your agent to confirm the current folder. Choose another project offers a native folder picker, GitHub selection, and manual path entry. The CLI also supports --current-project (interactive confirmation), --choose-folder (a picker on this machine), and --repository github.com/owner/repo alongside a folder choice to verify its Git origin. Cancelling or choosing a mismatched checkout stops setup before recording. GitHub selection does not change workspace policy.

Run setup from the project you want to record: --folder . includes that folder and its subfolders. Repeat --folder <path> for additional folders, or choose --all-projects explicitly. New connections stay paused without a capture choice; reconnecting without one preserves your existing rules. Existing exclusions remain in effect. Use lore scope check <folder> to verify. Learning repository scope controls where knowledge applies and is separate from capture scope.

Windows

Native Windows support is available in Lore 0.2.0 and newer. Use PowerShell on 64-bit Windows 10 (1809 or newer) or Windows 11. Git and the coding agents you want to connect must be installed on Windows too. The npm package uses the same commands as macOS and Linux:

npm.cmd install --global @lore-co/cli
lore.cmd connect --login --agent claude --agent codex --folder .
lore.cmd doctor

For a standalone installation:

irm https://uselore.co/install.ps1 | iex

It verifies the release checksum and installs lore.exe in %LOCALAPPDATA%\Lore\bin, then adds that directory to your user PATH. No administrator access or WSL is needed. lore update and lore uninstall also work with this installation.

Windows hooks use PowerShell. Lore protects local credentials and recordings with Windows access permissions. Automatic recovery adds Lore-owned functions to your PowerShell profiles; open a new terminal after connecting. If your organization blocks profile scripts, use lore run <agent> -- explicitly. Live sessions use Windows' ConPTY terminal support. Each agent's own platform requirements, permissions, and hook approval still apply.

Find the right command

Run lore help for the command list, lore help <command> for its use case, options and examples, or lore help self-host up for a subcommand. lore <command> --help works too. Help does not require a workspace connection.

Use ask to find existing knowledge, remember to save a reusable lesson, resume to pick up previous work, and continue to hand it to another agent. Use status to check connections and doctor when something is not working.

lore demo runs real Claude and Codex sessions in your connected workspace. It removes its temporary learning after the run; the sessions and delivery history remain available through the Sessions filter for Lore setup and tests. Native-agent acceptance tests use a separate disposable stack.

connect auto-detects the codex, claude, cursor, opencode, and polytoken executables plus existing Cursor, OpenCode, and Polytoken configuration directories. Repeat --agent claude, --agent codex, --agent cursor, or --agent opencode for an explicit headless install. --agent polytoken updates $XDG_CONFIG_HOME/polytoken/hooks.json (normally ~/.config/polytoken/hooks.json). --agent t3code detects and configures the supported Claude, Codex, Cursor, or OpenCode provider instances that T3 Code delegates to. It reads $T3CODE_HOME/userdata/settings.json or ~/.t3/userdata/settings.json, follows custom provider homes, and does not modify T3 settings or secrets. External OpenCode servers must be configured on the server. Cursor ACP sessions require a live canary because Cursor does not guarantee lifecycle hooks in ACP mode. Lore does not install a duplicate T3 lifecycle layer. --agent cowork is credential-only: it prepares the secure CLI config consumed by the separately uploaded Cowork MCP plugin without installing lifecycle hooks. Configuration is stored in ~/.lore/config.json with mode 0600 on macOS and Linux, or a private Windows ACL. --login opens a 10-minute dashboard approval and mints an attributed, revocable 90-day credential without exposing it in terminal or agent output. If the final login response is interrupted, the CLI retries within that window and receives the same credential. After saving it locally, the CLI confirms receipt so the approval can no longer be used. This requires an updated server; older servers may require another approval after a lost response. Use --no-open to print the approval URL without launching a browser. Before writing the local config or any agent integration, connect calls the authenticated workspace identity endpoint and validates the strict response and server version. Revoked credentials, unreachable servers, timeouts, and incompatible servers leave local configuration untouched. Either LORE_WORKSPACE_TOKEN or the legacy LORE_TOKEN can provide the token; if both are set, they must match. New token connections default to https://api.uselore.co and use https://uselore.co for receipt links. Self-hosted deployments must pass --url and may pass --dashboard-url; reconnecting without a new token keeps the existing self-hosted endpoints. Manual --token and environment credentials remain supported for CI and non-interactive hosts, and for users who prefer copying a token from the dashboard:

lore connect \
  --folder . \
  --token "your_workspace_token" \
  --agent claude

Keep manual tokens out of agent prompts and use a separate revocable token per machine or integration. For copy-paste hosted and self-host prompts, human approval points, verification, and rollback, see the agent-driven setup guide.

For a fully local API-only deployment, the CLI can keep its generated bootstrap credential internal while connecting agents:

lore self-host up --headless --connect --agent claude --agent codex
lore connect --folder .

Dashboard self-hosting uses lore self-host up, human signup, then:

lore connect --login --folder . --url http://127.0.0.1:3001 \
  --dashboard-url http://127.0.0.1:3000

For a review-first OpenCode rollout, follow the plugin guide.

Query shared context

lore connect enables recovery when two supported clients are installed. Use --fallback <agent> to choose a destination or --no-recovery to opt out. Independent routes use lore recovery enable --from opencode --to devin. Claude, Codex, OpenCode, Devin CLI, Cursor Agent, Copilot CLI and Polytoken can receive work locally or on a configured SSH worker. All support checkpointed process-exit recovery and Ctrl+]; native failure coverage varies by host. Setup adds reversible shell wrappers and checkpoint integrations. Open a fresh terminal and approve Codex's new hooks in /hooks when prompted. Explicit T3, Copilot VS Code, and Cowork connections also install their host adapters. T3 observes local session failures. Copilot CLI observes terminal session errors after retries. Copilot's editor integration reads active responses before autosave when request IDs identify the session; new unsaved and background chats retain the saved-session delay. Cowork captures shared-folder checkpoints, with native cap delivery still unverified. Polytoken observes its authenticated daemon's prompt-bound failures. See the recovery guide for exact coverage and evidence.

lore ask "How should payment retries work?"
lore ask "What did the previous agent already try?" --repo acme/billing
lore ask "What constraints apply here?" --json

ask queries durable knowledge and prior work sessions together. Results explain why each memory matched and show its scope, status, freshness, category, source agent, and source session, followed by matching prior sessions with excerpts. --repo and --project rank knowledge and sessions for that repository or project, --agent identifies the caller, --limit caps knowledge results (1-20), --no-sessions skips session context, and --json prints the machine-readable response. Requires a connected workspace (lore connect) and a server that exposes POST /v1/ask.

Use Lore with your agent

Choose lore in your agent's skills to find shared knowledge or save what you learned. For example:

“Ask Lore what we decided about authentication.”
“Remember this session for acme/app.”
“Save only the design decisions in Lore.”

When asked to remember, the skill saves confirmed decisions and their reasoning, checks existing learnings, and uses the current repository's connection. Saving requires write access and may need workspace review; it does not make a learning a Required rule.

After updating the CLI, run lore connect and restart your agent. Setup replaces the previous lore-remember skill with lore, preserving customer-edited files. Claude Code also supports /lore; Codex supports $lore.

The skill is installed in ~/.agents/skills/lore for Codex, Cursor, Copilot and OpenCode, and in the configured Claude directory's skills/lore. Cowork and Copilot bundles include it too. Polytoken does not receive a skill installation.

Installation paths follow the official Codex, Claude Code, Copilot, Cursor, and OpenCode skill conventions.

Save knowledge manually

lore remember "Use pnpm for this repository." --repo acme/app --category convention
lore remember "Payment retries must use exponential backoff." --project billing
lore remember "The legacy endpoint is deprecated." --agent codex --json

remember saves an explicit learning using your existing lore connect credentials. Supply the statement as a quoted argument; multiline statements are supported inside that argument. Use --repo, --project, --path, or --component to limit where it applies. With no scope flags, it is available workspace-wide; the current repository is not inferred. The connected workspace determines the organization.

--category defaults to other; run lore remember --help for the supported categories. --agent identifies the source and defaults to human; --session preserves its actual session ID when known. The command prints the saved learning's ID, content, scope, category, and status, and reports an existing learning when the server deduplicates it. --json returns the full { memory, inserted } response for scripts. Use -- before statement text that begins with a dash. Manual saves do not require agent hooks or MCP write tools.

Make this repeatable

After completing a task in a connected native agent, say “Make this repeatable.” Lore's prompt hook supplies instructions for reviewing the recorded work and saving an approach in Learnings. To reuse it, ask your agent to use the saved approach for the next task. The agent asks for new inputs, checks prerequisites, and records its result against the saved version.

lore approach --help describes the JSON commands used by agents. These require an updated CLI and API. MCP hosts can use the equivalent tools with writes enabled. See Make this repeatable for the workflow and its limits.

Repository skills

Use Learnings → Skills to add selected SKILL.md files and enable or disable them for a repository. Product discipline is included for all repositories by default.

lore skill list
lore skill show llm-product-discipline
lore skill discover --folder ./my-project
lore skill import --file .agents/skills/my-skill/SKILL.md

Discovery is local. CLI imports propose skills for a workspace member to review and enable. Use --all-repositories when importing to propose a workspace-wide skill; an owner or admin must enable it. Skills guide agents under their existing permissions; supporting scripts and assets stay in the source repository. See Repository skills for imports and MCP tools.

Context Guard

In Learnings, select a rule template for pushes, edits to a file or folder, deployments, commits, or terminal commands. Push rules can cover selected branches (for example main and release/v1) or all branches. Settings are saved separately from your explanation; changing the wording does not silently change the check. An owner or admin enables Ask before conflicting actions, and Enforce mode pauses conflicting actions for approval in supported pre-action integrations.

Branch checks use the remote destination, including HEAD:main, multiple refspecs and branch deletion. Native hooks can read local Git configuration to resolve a simple implicit push or a source-only refspec. Unknown destinations, wildcard pushes and broad operations such as --mirror require approval. A known push to another branch is unaffected by this rule. This is a check of reported agent actions, not a replacement for server-side branch protection; arbitrary scripts and tools without pre-action support are not covered.

Update connected clients before enabling the new templates. An older client cannot evaluate a structured saved policy offline and will pause until it can verify enforcement again. Existing supported written rules remain valid.

lore guard status                  # effective mode here, and why
lore guard assist                  # set the workspace default
lore guard enforce --repo          # override for the repo you're in
lore guard clear-override --repo   # remove that override
lore guard off                     # workspace default back to off
lore guard approve <check-id>      # confirm a blocked action

With guard on, connected agents receive up to three highly relevant learnings (with sources) before file edits, commits, deploys, and destructive commands. In enforce mode, actions that conflict with a learning marked as a Required rule pause: Claude Code shows its native confirmation dialog, Codex denies the call with approve-and-retry instructions, and Cursor and OpenCode block the call and include the lore guard approve command in the message. Native hooks and OpenCode preserve known Enforce during outages using a verified saved policy and block Guard-eligible actions if no usable policy exists. Changing modes requires an owner- or admin-attributed credential; status and approve work for every member. All subcommands support --json. Guard output uses the same relevance, provenance, scope, status, and freshness explanation as ask. Every decision, including Off, plus confirmations and policy changes is recorded as a content-free guard_check audit event.

Update the standalone CLI

lore update
lore update --version v0.2.17

update resolves the latest release to an exact tag, or uses the exact v-prefixed semantic version passed with --version. It verifies the selected binary against that release's SHA256SUMS and checks the staged binary's version before replacing the current target. LORE_REPO selects another GitHub repository and LORE_RELEASE_BASE_URL selects an HTTPS release mirror; LORE_BIN_DIR overrides the standalone install directory.

The command merges Lore-owned entries into ~/.codex/hooks.json, ~/.claude/settings.json, and ~/.cursor/hooks.json, and merges @lore-co/opencode into the plugin array in ~/.config/opencode/opencode.json. Existing settings, hooks, keys, and plugins are retained. Changed agent config files receive timestamped backups, and rerunning connect does not duplicate entries or backups.

Inspect or remove

lore status
lore doctor
lore disconnect
lore uninstall

status, doctor, and disconnect also support --json. doctor checks public /health/ready separately from authenticated workspace identity so unreachable, unready, and unauthorized states remain distinct.

status and doctor report the durable outbox, oldest pending capture, and the last observed invocation. doctor also asks Codex for its discovered Lore hooks and approval state. New or changed Codex hooks need review in /hooks; Lore never writes trust records or bypasses that review. Unsupported or unreachable host diagnostics are reported as unverified, not approved. After installation, restart the agent, complete a turn, and check for fresh activity. API access and installed files alone do not establish recording.

The diagnostics also report verified snapshots and their local age, trust keys, local Guard coverage and latency, context fallback rate, declared agent capabilities, exact installation state, and last invocation health. doctor also reads the authenticated workspace operational aggregate: server capture/embedding backlog, dead letters, Guard failures/latency, retrieval corrections, and the zero-target durable silent-failure invariant. Checks compare every expected event, matcher, command, timeout, and plugin entry; equal hook counts do not hide a missing, changed, or duplicate unit. Copied hook files also carry their Lore runtime version and SHA-256 installation manifest, so old, modified, oversized, non-regular, or symlinked runtime files are reported as stale. Inspection does not create missing store directories or repair unsafe permissions before reporting them.

status --json is versioned as lore-cli-status-v1. Invocation states are never_observed, successful, failed, incomplete, or unknown. They come from actual hook/plugin calls, not heartbeats. Lore stores only an integration ID, random local attempt ID, timestamps, runtime version, and fixed failure code—never prompts, responses, commands, files, repositories, sessions, credentials, hostnames, or raw errors. Idle event-driven agents do not become unhealthy solely because time passed. Per-integration locks keep optional health updates separate from capture and cache work. A disposable helper process imposes a hard write deadline, so telemetry cannot indefinitely stall an agent hook. It runs detached, receives metadata through a private pipe, and does not inherit host credentials. Invalid health state is reported as unknown and quarantined on the next invocation; a mismatched observed OpenCode version is reported as stale.

Optional command usage reporting is separate from these diagnostic counters and is off by default. Run lore telemetry on to send command names, success or failure, elapsed time, OS, and CLI version to your connected Lore server. lore telemetry off disables it; lore telemetry status shows the current choice. Reporting never includes arguments, prompts, code, paths, or raw errors. Internal hooks and CI runs are excluded. LORE_TELEMETRY=0 or DO_NOT_TRACK=1 disables reporting; LORE_TELEMETRY=1 enables it for a process. A request has a 200 ms deadline and failures do not affect the command. Offline, unconnected, or interrupted commands may not be reported. Self-hosted connections report only to their configured server and never to Lore's hosted service.

These machine-local counters are never uploaded as mandatory telemetry. Hosted and self-hosted servers expose only their own content-free aggregates; prompts, commands, memory content, paths, credentials, hostnames, and raw errors are excluded.

disconnect removes only hook handlers marked as Lore-owned and Lore's OpenCode plugin entry, then deletes Lore's credential, legacy hook runtime, legacy pending state, and legacy retry queue. The Reliability v1 store is retained so acknowledged local work and visible dead letters are never silently discarded. It does not remove the installed lore binary or restore a whole backup over newer agent settings.

lore uninstall disconnects the machine and removes the CLI. It shows the installation it will remove and asks for confirmation. Standalone installations remove the running Lore binary; global npm installations use npm to remove the package from its original prefix. Other installation types receive instructions without changing anything. For scripts, use lore uninstall --yes --json. If npm reports a global directory that cannot be resolved, uninstall explains which path failed and stops before disconnecting agents or removing the CLI. Check npm config get prefix and retry with the npm configuration used to install Lore.

Shared learnings, server data, local recordings, pending durable captures, and backups are retained. Uninstall does not stop a self-hosted server or change other machines. Restart your agents and open a new terminal afterward so any loaded Lore integrations are cleared. Use lore disconnect when you want to keep the CLI installed.

During a live retrieval outage, connected native hooks and OpenCode can use one relevant, reverified workspace context snapshot when the current repository is known. Repository and path scopes are reapplied before injection. Cached context is clearly labeled fresh or stale, expires from Assist eligibility after seven days, and is never used to authorize offline Guard enforcement.

One-command self-hosting

The published CLI embeds the canonical production Compose asset, so no repository clone is needed:

lore self-host up
lore self-host status --json
lore self-host down

The stack pulls ghcr.io/treadiehq/lore-api and lore-web. Those images are private. Access to the packages is not enough by itself: Docker must prove who you are. After you have been granted Read on both packages, log in once, then start the stack:

echo "$GHCR_TOKEN" | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin
lore self-host up

Use a GitHub token with read:packages. You do not need the Lore source repository. lore self-host does not log in for you.

up creates ~/.lore/self-host with mode 0700 and stores its Compose, environment, and state files with mode 0600. It generates a PostgreSQL secret, starts semver-pinned images, waits for /health/ready, and prints the signup and login URLs. Sign up normally, then create connector tokens on Connect. Loopback deployments write magic links to the API container logs; public origins require RESEND_API_KEY and AUTH_EMAIL_FROM. Retries reuse all state and secrets. --headless additionally generates an environment-provisioned workspace token because no dashboard is available. Use --state-dir, --image-tag, --api-port, --dashboard-port, and --origin for dashboard deployments; --organization and --name configure headless workspaces. Every command has subcommand-specific --help, and up, down, and status support --json.

down preserves the PostgreSQL volume. Destructive removal requires both --volumes --yes.

Runtime behavior

Cursor installs five hooks and a lore-native MCP server. Its sessionStart hook instructs the agent to call lore_context before each request and lore_complete after its response. The bridge retrieves scoped context, captures teachings, and stages prior attempts even in CLI print mode. Repository identity comes from the native session; MCP input cannot override it. Credentials remain in Lore's protected config. Keep the server enabled, reconnect with the updated CLI (lore connect --agent cursor), and start a new conversation to activate it. lore status checks all five hooks plus the MCP server. Other MCP entries are preserved during connect and disconnect.

The Claude/Codex/Cursor/Polytoken command-hook handler:

reads native hook JSON from standard input and normalizes Cursor and Polytoken event names;
observes and enriches the first prompt in a new session;
uses last_assistant_message, Cursor's afterAgentResponse, or Polytoken's post_model_turn, not a potentially stale transcript;
writes redacted captures and stable idempotency keys to the crash-safe ~/.lore/store-v1 outbox before the first network attempt;
retries FIFO captures with bounded backoff, preserving authentication failures and permanent dead letters for inspection;
verifies workspace-bound Ed25519 context and Guard snapshots before caching them for later reliability steps;
runs Context Guard checks at PreToolUse (Cursor: beforeShellExecution) boundaries when the workspace enables guard, with local mode and cooldown caches so repeated actions stay quiet;
redacts common and contextual credentials, authenticated URLs, authorization headers, cookies, provider tokens, and private keys before transport;
re-scans returned context immediately before Claude, Codex, Cursor, or Polytoken injection and preserves [REDACTED:<KIND>] audit markers;
times out network calls and always fails open without writing hook errors.

First prompts use POST /v1/observations and audited POST /v1/context/deliveries. Paired turns use POST /v1/turns with a workspace bearer token and an Idempotency-Key header. Automatic teachings default to repository scope and follow the workspace learning policy. In proposal_only mode, every automatic capture remains proposed and cannot be retrieved or injected until dashboard review activates it. Rejected, suppressed, superseded, and deleted learnings are also excluded. Dirty files and the current directory remain task relevance evidence and do not narrow every learning. Only an explicit correction with clear team-, company, organization-, or all-repositories evidence may become organization-only and apply across repositories. Native retrieval still requires a strong lexical, structural, symbol, or semantic match. Observations, paired turns, OpenCode plugin events, and deliveries are visible through Lore activity. OpenCode uses its plugin lifecycle and never runs through the command-hook parser.

External hosts

lore host gives local services and CI jobs a noninteractive bridge to the strict audited endpoints:

LORE_API_URL=https://api.uselore.co \
LORE_WORKSPACE_TOKEN=... \
  lore host deliver --input delivery.json --output prompt

cat webhook-observation.json |
  lore host observe --input - --output json

lore host turn --input incident-turn.json \
  --idempotency-key incident-42:reply-3 \
  --output prompt

deliver, observe, and turn accept the exact JSON bodies for POST /v1/context/deliveries, POST /v1/observations, and POST /v1/turns. There is no interactive or implicit-stdin fallback: pass --input <file|->. json output contains the complete audited response; context prints only returned context; prompt safely places that context before the original task or current user prompt. Standard output contains only the selected result.

Authentication comes from LORE_API_URL plus LORE_WORKSPACE_TOKEN (or LORE_TOKEN), or ~/.lore/config.json. Secret command-line flags are intentionally unavailable. Requests have a bounded timeout. Run lore host --help and lore host turn --help for endpoint-specific examples. Use stable connector, event, and session IDs from the calling model service, CI run, webhook, or incident; do not generate a new event ID when retrying. This bridge is a one-time host integration: the host must call it before and after model turns. lore connect cannot intercept an arbitrary external model API or bot by itself. The Lore web/wiki service is optional; the bridge needs only a reachable headless Lore API.

Image attachments

Image storage is shared across agents. Codex and Claude Code native hooks read embedded images from matching user messages in their local transcripts. OpenCode captures structured user and completed-assistant image parts. Devin CLI captures local image references in multimodal ATIF exports. Native hooks also accept image parts or explicit file attachments supplied by a host.

Lore saves the supplied bytes separately from conversation text and shows private thumbnails in sessions and learning-source evidence. Transcript images must match the user message, session, and capture time. Paths in ordinary prose are never read, and remote image URLs are not fetched automatically.

PNG, JPEG, WebP, and GIF are supported, up to 5 MiB and 40 megapixels per image, with six images per event. Capture retries at Stop if the transcript was not ready when the prompt hook ran. Uploads use the durable outbox and retry on later hooks, draining up to six images within a bounded upload window. Integrations without image data in their hooks use the shared SDK/API or MCP attach_image tool. Cursor currently omits pasted images from its prompt-hook attachments; text-only Copilot, Cowork, or cloud exports likewise need the source to explicitly provide the image bytes. A filename alone is not a captured image.

The API and dashboard must include migration 0027_event_images, and installed hooks must be refreshed with the updated CLI. Existing text-only events are not automatically backfilled; unavailable originals remain labeled in the session.

Devin sessions

For local Devin CLI sessions, connect Lore first, then run:

lore devin cli setup
# Open a new terminal:
devin

The shell integration enables --export automatically and records completed user/assistant turns, including resumed sessions. Lore supplies context through the prompt hook and reads assistant replies from the export, so Stop payloads without assistant text are supported. In scripts, use lore devin cli -- -p "Your task". Run lore devin cli status to check the last capture, lore devin cli sync to retry uploads, and lore devin cli off to remove the integration. Sign-in, workspace trust, and Devin permissions remain under Devin's control. See capture boundaries and storage.

Devin Cloud

Create a Lore-enriched Devin session, then send later prompts through the same audited context-delivery path:

DEVIN_API_KEY=... DEVIN_ORG_ID=... \
  lore devin start \
  --repo owner/repository \
  --prompt "Fix the failing tests"

DEVIN_API_KEY=... DEVIN_ORG_ID=... \
  lore devin prompt \
  --session devin-session-id \
  --repo owner/repository \
  --prompt "Apply the reviewer correction"

The Lore API must also have Devin polling enabled with the same DEVIN_API_KEY and DEVIN_ORG_ID, and the repository must appear in DEVIN_REPOSITORY_ALLOWLIST. lore devin setup checks Devin API access and authenticated Lore workspace access. It reports recording as unverified; it does not check the server's polling configuration or register a session. start performs authenticated delivery and poller-registration checks. Confirm a captured Devin entry in Sessions after the session has messages to poll.

Both commands retrieve Lore context with a stable delivery event and receipt. devin start registers the created session for transcript polling. devin prompt re-registers the session before sending, so a paused poller can capture the later correction. Prompts can also come from --prompt-file or explicit --stdin; --project narrows retrieval and polling. Use --message-as-user-id on devin prompt when Devin impersonation is configured. Later prompts entered directly in Devin's UI do not pass through Lore delivery and are not enriched. If the session was registered, transcript polling can still capture a correction after the fact.

Lore credentials come from LORE_API_URL plus LORE_WORKSPACE_TOKEN, or from the stored ~/.lore/config.json. Devin credentials come from DEVIN_API_KEY and DEVIN_ORG_ID. Credential flags are intentionally unavailable. Run lore devin start --help or lore devin prompt --help for copy-pasteable examples.

GitHub reviews

Install Lore-owned Codex and Devin review workflows into the current repository:

OPENAI_API_KEY=... DEVIN_API_KEY=... DEVIN_ORG_ID=org-... \
  lore connect github \
  --repo owner/repository \
  --configure-secrets

The command overwrites three fixed Lore workflow files and the Lore review schema without committing them. Review or back up existing files first. --configure-secrets requires authenticated gh access and updates the named Actions secrets and variables in the target repository. Codex uses the official Codex action. Devin uses a normal v3 session because the dedicated Devin Review API cannot accept dynamic Lore context. Reviews run only for same-repository, non-draft pull requests bearing the corresponding lore:codex-review or lore:devin-review label.

Generated jobs require a published standalone binary release and default to treadiehq/lore-releases at v0.2.17. Set LORE_CLI_REPOSITORY to the publicly readable owner/repository and LORE_CLI_VERSION to an existing release tag when using another release source.

The workflows require secret LORE_WORKSPACE_TOKEN and variable LORE_API_URL. Codex additionally requires secret OPENAI_API_KEY. Devin additionally requires secret DEVIN_API_KEY and variable DEVIN_ORG_ID. Codex separates a read-only review job from its pull-requests: write posting job. The Devin review job uses contents: read and pull-requests: write. The correction workflow has read-only GitHub permissions. Native /devin review cannot accept dynamic Lore context; the generated Lore workflow uses a normal capped Devin session instead. The private Devin hook prototype is not currently an installable managed plugin.

An authorized maintainer can turn a false-positive bot comment into shared knowledge with:

/lore correct <Lore bot comment URL>

The correction and current behavior go here.

Production guidance

Use a dedicated workspace token for each person, machine, or integration.
Connect only to an HTTPS Lore API outside local development.
Run lore doctor after installation and configuration changes.
Keep provider credentials in environment variables or GitHub Actions secrets.
After standalone publication, pin LORE_CLI_VERSION in automated workflows and update it deliberately.

For source builds, self-hosting, tests, and release internals, see the documentation index.

Private links

Use lore share learning <id>, lore share session <id> --event <event-id>, or lore share delivery <id> --learning <learning-id> to return an existing workspace link. The anchor flags are optional. Add --json for structured output. IDs come from Lore results, such as lore ask --json.

MCP exposes the read-only share_lore tool with kind, id, and optional eventId or learningId. The SDK offers client.share(...). These resolve the resource using the current credential before returning a link. They do not publish content or grant access; recipients must sign in to the same workspace.

Hosted connections use https://uselore.co. For self-hosting, connect with --dashboard-url https://lore.example.com, set LORE_DASHBOARD_URL for MCP, or pass dashboardUrl to the SDK. The URL must be an HTTP(S) origin.

Managed Devin and Cursor jobs can produce offers in the hosted Recovery page, currently restricted to platform admins for testing. Customer workspaces do not see the page or recovery notices. CLI runners need a token attributed to an active platform admin. Pair a desktop checkout with lore recovery cloud runner --name my-machine to launch an installed agent after dashboard acceptance. Provider setup, SSH workers, managed destinations, paired workspace exports with verified restoration, and the pushed-checkpoint fallback when no exporter is available are documented in recovery.

Limit where Lore runs

Owners and admins choose team repositories in Settings → Repositories. Members use lore config open to set their own folder rules. Both must allow the project.

For multiple accounts or workspaces, connect each with lore connect --login --name <name> and edit its folders with lore config open --connection <name>. Each folder must match exactly one connection. Run lore connections to list them and lore scope check [folder] to check a project.

See folder and repository settings for setup and examples.