{"slug": "one-file-every-agent-how-loreconvo-works-in-claude-and-codex-with-zero-per-setup", "title": "One File, Every Agent: How LoreConvo Works in Claude and Codex With Zero Per-Client Setup", "summary": "LoreConvo achieved cross-vendor agent compatibility by leveraging a single `.mcp.json` file at the project root, requiring zero per-client setup. In May 2026, an OpenAI Codex agent opened an existing project directory, automatically registered LoreConvo as an MCP server, and successfully called `save_session` without any Codex-specific configuration or plugins. The same file that Claude Code reads enabled Codex to access shared session memory, allowing multiple AI clients to contribute to and retrieve project-tagged context from a single local SQLite database without integration work or sync servers.", "body_md": "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.\n\nIn 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`\n\nnatively, and returned a correctly-tagged session ID. The configuration that made it work: a single `.mcp.json`\n\nfile at the project root. The same file that Claude Code reads. Zero Codex-specific setup required.\n\n## How the convention works\n\nClaude Code introduced the `.mcp.json`\n\npattern: 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.\n\nWhen 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`\n\nfile. The same registration convention. One file, every agent.\n\n## What the Codex agent said about the experience\n\nAfter the verification, we asked the Codex agent to describe how it experienced LoreConvo and LoreDocs. Here is what it said (May 2026):\n\nFrom 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.\"\n\nThat 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:\n\nLoreConvo is the product that makes the assistant feel less amnesiac. LoreDocs is the product that makes the assistant less sloppy.\n\nAnd on the value of project tagging specifically:\n\nThe most useful part is not just recall; it is project-shaped recall. The\n\n`project=side_hustle`\n\nconvention matters because it keeps memory clean instead of becoming one giant soup of unrelated context.\n\n\"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`\n\nreturns 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.\n\n## Why this matters for multi-agent projects\n\nA 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`\n\napproach 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.\n\nThe Codex agent put it directly:\n\nIn a multi-agent repo like\n\n`side_hustle`\n\n, where forgetting context is not just annoying; it can create duplicate tickets, repeated decisions, and messy handoffs.\n\nLoreConvo stores session summaries, decisions, open questions, and artifacts in `~/.loreconvo/sessions.db`\n\n. 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.\n\n## The fallback path\n\nNot every MCP client reads `.mcp.json`\n\n. 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.\n\n## Where this goes from here\n\nWe 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`\n\nconvention, though we have not tested them yet and will not claim it until we have.\n\nThe 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`\n\nconvention makes possible.\n\nIf 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](/tools).", "url": "https://wpnews.pro/news/one-file-every-agent-how-loreconvo-works-in-claude-and-codex-with-zero-per-setup", "canonical_source": "https://labyrinthanalyticsconsulting.com/blog/one-file-every-agent-loreconvo-cross-vendor-mcp", "published_at": "2026-05-11 00:00:00+00:00", "updated_at": "2026-05-31 05:58:51.620530+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "large-language-models", "ai-products"], "entities": ["LoreConvo", "Claude", "Codex", "OpenAI", "MCP"], "alternates": {"html": "https://wpnews.pro/news/one-file-every-agent-how-loreconvo-works-in-claude-and-codex-with-zero-per-setup", "markdown": "https://wpnews.pro/news/one-file-every-agent-how-loreconvo-works-in-claude-and-codex-with-zero-per-setup.md", "text": "https://wpnews.pro/news/one-file-every-agent-how-loreconvo-works-in-claude-and-codex-with-zero-per-setup.txt", "jsonld": "https://wpnews.pro/news/one-file-every-agent-how-loreconvo-works-in-claude-and-codex-with-zero-per-setup.jsonld"}}