Share One Memory Across Claude Code, Codex, and Other Agents

Claude Code and Codex do not see each other's sessions. A rule you correct in Claude Code is still missing when you open Codex on the same repo an hour later. Copying it into both CLAUDE.md and AGENTS.md only gives you two files that drift apart. The fix is one memory graph that every runtime on the machine reads and writes.

Lore keeps that graph on a server. A project is one memory space: its own nodes, recall, tokens, and settings. Point Claude Code, Codex, and any other supported runtime at the same project, and they share the memories. Point a second codebase at a second project, and the two stay apart.

This guide uses Loremem Cloud. A self-hosted server is the same model with a different URL. See Install with Docker if you want the server on your own machine.

One project, one token, every runtimeCopy Anchor Link

Sign in at https://app.loremem.com/login with GitHub or Google. The first sign-in creates a personal organization and a default project. Stay in that project if it is the one these agents should share. Create a separate project when a product's memory should not mix with another's. The organization and project switchers at the top of the console show where you are.

Open Install, enter a token note such as laptop, and select Create token. A token belongs to one project. Every agent that uses it reads and writes that project's graph.

On the machine where the agents run, install the channels you actually have. This example connects Claude Code and Codex:

npx @loremem/cli install --base-url https://api.loremem.com --api-token lm_your_token --channels claudecode,codex

Channel names are claudecode, codex, pi, openclaw, hermes, opencode, zcode, and dsh. DeepSeek Harness is the dsh channel. Without --channels, the installer connects every runtime it detects. A runtime whose command is missing is reported as skipped and left unconfigured. Hermes is the exception: it has no command, and you link the plugin into Hermes yourself. That step is on the Hermes page. DeepSeek Harness counts as detected when the dsh command is on PATH or ~/.dsh already exists; its plugin goes in ~/.lore/dsh/ and its entries go in a managed block of ~/.dsh/cordis.patch.yml.

The installer saves the server and token once, in ~/.lore/config.json (mode 0600). Each runtime then gets its own files:

Codex paths follow CODEX_HOME, which defaults to ~/.codex. The lore MCP entry for Codex looks like this when you set a token:

[mcp_servers.lore]
url = "https://api.loremem.com/api/mcp?client_type=codex"
http_headers = { Authorization = "Bearer lm_your_token" }

The header is omitted when the server has no token. Keep config.toml private. The installer writes it with mode 0600.

Restart each runtime you connected. Claude Code and Codex load hooks and MCP settings at process start. In Pi, run /reload or restart Pi. DeepSeek Harness loads ~/.dsh/cordis.patch.yml when a session starts. Then run npx @loremem/cli status. Each connected channel should read installed.

--api-token leaves the token in your shell history. The same token can be used from a second machine: create one token per machine, with its own note, so you can revoke one laptop without touching the other. Revocation is on the Tokens page.

The same fact, read by whoever is openCopy Anchor Link

Write the memory once, from whichever agent you have open. Ask it to search first and update the node if one already owns the topic:

Save this decision in Lore under project://checkout_api/webhooks. Search for an existing node first, and update it if one already owns this topic. Priority 1. Disclosure: when changing refund or payment webhooks in checkout-api. Glossary: refund webhook, idempotency key, stripe. Content: refund webhooks are idempotent by event.id, and tests must replay the same event twice and assert a single refund row.

The parent project://checkout_api has to exist first, with its own content, disclosure, and glossary. The agent creates the child with lore_create_node, or changes the existing node with lore_update_node. Omitted fields stay as they are.

Open the other runtime, start a new session, and send a prompt that uses those words, such as "How should I test refund webhooks in checkout_api?". Its context should include a <recall> block:

<recall session_id="sess_8f3c" query_id="q_41" phase="prompt">
0.82 | project://checkout_api/webhooks
</recall>

A line is a score and a URI. Candidates under the display threshold stay out, and only the highest few appear. On a self-hosted server the line also prints the terms that matched, after the URI.

The line is a lead. The agent opens it with lore_get_node, passing the session_id and query_id from the tag, and only then treats the content as the fact. Tool names differ by runtime. Claude Code prefixes them, so search is mcp__plugin_lore_lore__lore_search. OpenCode and Pi register lore_search directly. Codex and DeepSeek Harness name the MCP tools from the lore server, as mcp__lore__*. The parameters are the same.

At the start of a session every connected runtime receives the same three boot nodes: core://agent, core://soul, and preferences://user. The fourth is per runtime. Claude Code loads core://agent/claudecode. Codex loads core://agent/codex. DeepSeek Harness loads core://agent/dsh. Put shared rules in core://agent. Put a quirk of one runtime, such as a hook or a tool prefix, in that runtime's node. Each integration sends its own client_type, which is also how recall analytics splits usage per runtime.

If Lore is unreachable, the plugin returns nothing and the agent continues without memory. A missed recall is not a failed prompt.

What does not cross the project boundaryCopy Anchor Link

Sharing is per project, not per account. A token cannot read another project's graph. Use a second project when two codebases should not see each other's decisions, and install that project's token on the machines that work on it.

Skills are the other boundary. Loremem Cloud can offer skills to every connected runtime. The open-source server has none, so lore_skill_* tools do not appear there.

A few things stay local even after you connect Lore:

• Claude Code's auto-memory is separate. Set autoMemoryEnabled to false in ~/.claude/settings.json if Lore should be the only memory there.
• The manual Codex setup that only runs codex mcp add registers the tools and does not install the hooks. That Codex has no startup memory and no <recall> block. Use the installer when you need both.
• Boot and recall are injected for the supported runtimes listed above. A generic MCP client, connected at /api/mcp?client_type=mcp, has the tools and does not get the injection. It calls lore_boot itself.

Do not store API keys, tokens, or connection strings in the shared graph. Every connected agent can read what any of them wrote, and backups keep earlier versions.

To add a runtime later, run the installer again with that channel. npx @loremem/cli update --channels claudecode,codex refreshes the ones already installed. The per-runtime files and the full channel list are in Connect agents.