@lore-co/opencode

Structured user and completed-assistant image parts are stored with the recorded event through Lore's shared attachment API. Embedded raster data and explicit local file parts are supported; remote image URLs are not fetched. Images use the same durable outbox as captures, in separate records, and appear in sessions and learning-source evidence. Each image is limited to 5 MiB and 40 megapixels, with six images per event. Text-only exports cannot recover missing image bytes.

Fail-open Lore memory plugin for OpenCode. It observes prompts, injects scoped workspace context into the next system prompt, and can block guarded tools that conflict with a required rule.

Most people should not install this package by hand. lore connect adds it to OpenCode's plugin list and writes the workspace credentials.

curl -fsSL https://uselore.co/install.sh | bash
lore connect --login --agent opencode --folder .
lore doctor

That command merges @lore-co/opencode into the plugin array in ~/.config/opencode/opencode.json, keeps unrelated plugins, and writes a timestamped backup when the file changes.

Restart OpenCode to load the plugin, complete a turn, and run lore doctor again. Check Activity for a fresh OpenCode entry. An installed plugin entry or working API credential alone does not confirm that OpenCode has loaded and invoked the plugin.

Manual install

Use this only when you already have Lore credentials and want to wire the plugin yourself:

pnpm add --global @lore-co/opencode

Then add the package name to OpenCode's plugin array:

{
  "plugin": ["@lore-co/opencode"]
}

The plugin reads LORE_API_URL plus LORE_WORKSPACE_TOKEN (or LORE_TOKEN) from the environment. If those are unset, it falls back to ~/.lore/config.json from lore connect.

The package root exports only the plugin initializer because OpenCode invokes every exported value when loading a plugin. Integrations that use Lore's plugin helpers directly should import them from @lore-co/opencode/api.

Optional:

• LORE_OPENCODE_TIMEOUT_MS — request timeout, clamped to 100–5000 ms (default 2000).

Behavior

Start OpenCode as usual. The memory plugin needs no wrapper; optional agent recovery uses a separate configured wrapper. The plugin:

1. Observes the first user prompt and stages scoped active context.
2. On session idle, stages the latest completed assistant response.
3. Pairs the next user prompt with that staged response.
4. Checks edit, commit, deploy, and destructive bash tools against Lore Guard when the workspace has guard enabled.

When a CLI session resumes after exiting before the idle hook completed, Lore recovers its preceding response from OpenCode's session API. It excludes responses after the current prompt and replies already followed by another user prompt, so a restart does not attach stale responses to new work.

Capture, context, and Assist failures fail open so OpenCode continues. In Enforce mode, the tool call is blocked when a required rule matches or the verified saved policy cannot be retrieved (for example, during an outage); the thrown error tells the agent how the user can approve.

If saved Guard state is unreadable or corrupt, Lore attempts a live check. If the state remains unreadable and the live check fails, Guard-eligible actions are blocked until verification recovers or a valid audited emergency override applies. An older saved policy cannot establish whether enforcement has changed. This does not change behavior for a new installation with no saved policy or for a readable, explicit Off or Assist setting.

Node.js 22 or newer is required. The complete connector surface is in Connect agents.

Review-first use

Start with one repository and real conventions you can verify. In Lore Settings, set Automatic learning mode to Proposal only before capturing corrections. Every automatic capture then waits for review, and proposed learnings cannot be retrieved or injected. Manual learnings follow the workspace's normal permissions and review requirements.

Use a dedicated connection for the machine so its token can be revoked independently. Browser approval creates the token for you. A named manual token from Connect remains available with lore connect --token ... --agent opencode; keep its value out of agent prompts.

1. Start opencode in the repository and work normally. When correcting it, state the durable rule and where it applies. For example: “Every new catalog component needs a story file before merge. Keep that as this repository's convention.” Avoid asking it to remember everything.
2. Open the proposal in Learnings. Inspect the original source, statement, and scope. Exclude secrets and temporary task instructions.
3. Approve a useful proposal or decline it. A conflict may require replacing the existing learning or keeping it instead. Keep both only when both statements are valid in distinct scopes; narrow their scopes first. Broad workspace proposals and promotions require an owner or admin.
4. Start a fresh OpenCode session and request related work without repeating the rule. Inspect the lore-opencode-plugin delivery in Activity, or follow the learning on Connect. A receipt proves delivery; inspect the response separately to judge whether the model used it.

Before expanding use, check that source and scope are accurate, approved learnings reach relevant fresh sessions, and unrelated, pending, rejected, superseded, and forgotten learnings stay out of retrieval. Record missed corrections, false captures, irrelevant deliveries, and review time. Keep proposal-only mode until the review cost and capture quality are acceptable. Optional LLM conflict analysis is advisory and never activates a proposal by itself.

For a repeatable, credential-gated live check, see OpenCode acceptance. The fixture-based first-learning journey checks the dashboard flow without calling model providers.

Disconnect

Use Forget to stop future retrieval of an active learning while retaining history. Decline pending proposals that should never be used.

lore disconnect
lore status --json

Disconnect is machine-wide. It removes Lore-owned integrations and credentials, preserves unrelated host configuration, and retains the Reliability v1 store for acknowledged captures and invocation evidence. It does not delete server-side learnings or receipts. Reconnect any other agents that should stay connected, then revoke the old machine token in Lore.