Most tools that claim to support "any agent" mean they offer an API you can call. You write the integration, handle the auth, manage the retry logic. Support comes in the form of documentation. LoreConvo's approach to cross-vendor compatibility turned out to be different -- and we found out by accident.
In May 2026, we pointed an OpenAI Codex agent at an existing project directory without touching any Codex settings or installing any Codex plugin. The agent opened the project, registered LoreConvo as an MCP server, called save_session
natively, and returned a correctly-tagged session ID. The configuration that made it work: a single .mcp.json
file at the project root. The same file that Claude Code reads. Zero Codex-specific setup required.
How the convention works #
Claude Code introduced the .mcp.json
pattern: a project-local file that lists which MCP servers belong to this project. Drop the file at the root, and Claude Code registers those servers automatically on startup. License tokens stay in the file, which is gitignored by default, so credentials never leave the machine and the registration never gets committed to version control.
When Codex opened the same project, it applied the same logic. The Codex UI showed a permission prompt -- "Allow the loreconvo MCP server to run tool save_session?" -- and when approved, the call succeeded. Codex later confirmed this directly: "I'm able to use the Lore MCP servers in this session... no bypass script was needed there." The same .mcp.json
file. The same registration convention. One file, every agent.
What the Codex agent said about the experience #
After the verification, we asked the Codex agent to describe how it experienced LoreConvo and LoreDocs. Here is what it said (May 2026):
From a Codex and ChatGPT perspective, LoreConvo and LoreDocs feel like the difference between "being dropped into a room with no memory" and "walking back into an ongoing workshop where the bench still has labels on it." That metaphor captures the practical difference precisely. Without session memory, every agent interaction starts from zero. The agent does not know which decisions have already been made, which work is in progress, or which questions are still open. With LoreConvo, that context persists between sessions. The agent observed:
LoreConvo is the product that makes the assistant feel less amnesiac. LoreDocs is the product that makes the assistant less sloppy.
And on the value of project tagging specifically:
The most useful part is not just recall; it is project-shaped recall. The
project=side_hustle
convention matters because it keeps memory clean instead of becoming one giant soup of unrelated context.
"Project-shaped recall" is the right phrase for it. LoreConvo does not store everything in one undifferentiated pile. Sessions are tagged with a project name at save time, so recall for side_hustle
returns sessions from that project only. In a multi-agent environment where the same developer runs Claude Code, Codex, and scheduled agents in the same project, this keeps context clean regardless of which client saved it.
Why this matters for multi-agent projects #
A project with multiple AI clients -- a Claude Code session doing code review, a Codex session syncing documentation, a nightly scheduled agent running builds -- generates context from several sources. Previously, each client needed its own integration work to contribute to a shared memory layer. The .mcp.json
approach sidesteps that: every client that reads the file connects to the same LoreConvo instance, writes to the same local SQLite database, and tags sessions with the same project name. Memory becomes shared because the project conventions are shared, not because we built a sync server.
The Codex agent put it directly:
In a multi-agent repo like
side_hustle
, where forgetting context is not just annoying; it can create duplicate tickets, repeated decisions, and messy handoffs.
LoreConvo stores session summaries, decisions, open questions, and artifacts in ~/.loreconvo/sessions.db
. The database is a plain SQLite file you can inspect, back up, or move between machines. Full-text search across all sessions means that a decision from three weeks ago is retrievable in seconds, whether it was saved by Claude, Codex, or an automated run. Auto-save and auto-load hooks handle the session lifecycle for clients that support them.
The fallback path #
Not every MCP client reads .mcp.json
. For agents that do not -- or for environments where MCP registration is not desired -- LoreConvo ships Python fallback scripts that any agent capable of running Python can call directly. No MCP registration required, no install steps beyond having Python and the project on disk. The two-path design means the memory layer is available regardless of how the agent connects. Path one is the clean MCP experience; path two is the pragmatic one. Most users will never think about path two, which is exactly how it should be.
Where this goes from here #
We have verified LoreConvo working natively as an MCP server in Claude Code (all surfaces) and OpenAI Codex as of May 2026. Other MCP-compatible clients -- Cursor, Cline, Continue, and others -- likely work via the same .mcp.json
convention, though we have not tested them yet and will not claim it until we have.
The standard tagline is simple: one memory layer, every agent. It turns out that is not just positioning. It is a technical description of what the .mcp.json
convention makes possible.
If you are working in Claude Code, Codex, or any MCP-compatible environment and want persistent project memory with no cloud dependency, LoreConvo is at /tools.