Integrations
Connect Codex to Knownbase.
Add one MCP server and Codex gains project memory it can search before a task and write to after one — the same memory your other agents read.
The configuration
{
"mcpServers": {
"knownbase": {
"url": "https://knownbase.dev/mcp"
}
}
}
If your build supports OAuth for remote MCP servers, that's everything — it opens a browser on first use. Otherwise add a bearer header, below.
Step by step
- Create a workspace. Sign up free; no card required.
- Add the server entry above to your Codex MCP configuration.
- Authenticate. With OAuth, the first tool call opens a browser and lets you pick a workspace. Without it, generate a key in Settings → Workspace & MCP and add the header shown below.
- Add the AGENTS.md section so Codex knows when to reach for it.
API-key configuration
{
"mcpServers": {
"knownbase": {
"url": "https://knownbase.dev/mcp",
"headers": {
"Authorization": "Bearer kb_YOUR_KEY_HERE"
}
}
}
}
Keys are shown in full once. They can be marked read-only, scoped to a single project, given an expiry, and revoked individually.
Tell Codex when to use it
## Project memory Persistent project memory is available via the `knownbase` MCP server. Before starting a task, `search_notes` for decisions, constraints and prior debugging findings about the area you're touching. After the task, `upsert_note` anything durable that isn't visible in the code: a decision and its reasoning, a root cause, a constraint, an approach that was tried and rejected, or a handoff if you're stopping mid-task. Do not store code, transcripts, or unconfirmed speculation.
What the agent can do once connected
search_notes— find notes by query, project, tag, status or last-modified date. Returns snippets and metadata rather than full bodies, so searching is cheap; passincludeBody:truewhen you want everything inline.get_note/get_notes— read one note in full, or up to 50 by id in one call, with resolved[[links]]and backlinks.upsert_note— create or update. Updates are partial: omitted fields are left alone, so fixing a tag can't blank the body.list_projects— every project with note counts by status.list_note_revisions/get_note_revision— how a note changed, and what it used to say.delete_note— soft delete; restorable from the dashboard trash.backup_project— full content for one project, returned inline.
Every call is scoped to the workspace the credential belongs to. A key can additionally be marked read-only, or restricted to a single project — in which case notes in other projects are invisible to it, not merely refused.
Related
- Persistent memory for Codex, explained
- Sharing project context between Claude Code and Codex
- Connect Claude Code to the same workspace
- Full MCP tool reference
FAQ
Which Codex surfaces does this work with?
Any that can talk to an MCP server. Configuration lives wherever your Codex build keeps its MCP server list; the entry itself is the same URL in every case. Builds with OAuth support need no key at all; builds without one use a bearer header.
Do I need to install anything?
No. It's a remote server, so it's a URL plus authentication. Nothing runs locally, which also means the same workspace is reachable from a different machine.
Can Codex and Claude Code use the same notes?
Yes — point both at the same workspace. That's the main reason to keep memory outside the tool: whichever agent learns something, every other one can retrieve it.
What should go in AGENTS.md and what should go in memory?
AGENTS.md holds rules: how to behave in this repo, what to run, what not to touch. It's loaded in full every run, so it has to stay short. Memory holds what has been learned: decisions, root causes, constraints, rejected approaches. It's searched on demand, so it can grow without limit.
Give Codex a memory it shares with your other agents
One endpoint, one workspace, every MCP client. Free plan, no card required.
Create free workspace