Neotoma with Codex
Codex runs tasks in sandboxed environments with session-scoped context. Neotoma adds persistent memory that survives across sessions, tasks, and tools. The CLI provides a fallback when MCP is not available.
Looking for ChatGPT (conversations, custom GPTs, or developer-mode MCP)? See Neotoma with ChatGPT.
What Codex provides
- Sandbox environment with project access for each task
- Session-scoped context within the current task execution
- MCP server support via
.codex/config.toml(stdio and HTTP transports with OAuth) - Can itself run as an MCP server for integration with other MCP clients
What Codex doesn't handle
- Memory that persists across task executions; each sandbox starts fresh
- Entity resolution or structured data storage
- Cross-tool access; sandbox state is isolated per task
Deterministic guarantees Neotoma provides
- Persistent memory graph accessible across all Codex tasks
- Deterministic state: same observations always produce the same entity snapshots
- Provenance trail for every stored fact
- CLI fallback for direct terminal access when MCP is not configured
Using them together
Codex provides the execution sandbox; Neotoma provides the persistent state layer. Each sandbox starts fresh, but Neotoma carries structured memory across every task.
Getting started
Copy this prompt into Codex to have it read the evaluation page, inspect your tool, workspace, and configuration context, then judge whether Neotoma fits your real workflow and what to persist first.
Read https://neotoma.io/evaluate. Before you answer, inspect any broader tool, workspace, and configuration context you can access so you assess my real workflow rather than just this chat. Then assess whether Neotoma fits my workflow, what data would be highest value to persist first, and what I should do next.Once Neotoma has been evaluated, installed if needed, and activated with your first data, choose an integration path:
Codex documentation
- MCP in Codex (connecting tools via config.toml)
- Config basics (configuration fundamentals)
- CLI reference (command line options)
Before and after: Codex with Neotoma
“Continue where we left off yesterday.”
Resuming based on thread from two weeks ago.
Resuming yesterday’s thread on the migration plan. 3 open tasks remaining.
“What did I commit to with Sarah last week?”
No commitments found.
You committed to sending the architecture doc by Friday. Sarah’s email updated Mar 28.
“How much did we spend on cloud hosting last month?”
No hosting expenses found.
$847 across AWS and Vercel, up 12% from February.
After you connect
Once Neotoma is running, try these starter commands in Codex to see cross-session memory in action:
Store a contact
“Remember that Sarah Chen's email is sarah@newstartup.io — she's the CTO at NewStartup.”
Store a task
“I need to send the architecture doc to Sarah by Friday.”
Recall across sessions
“What do I know about Sarah? What did I commit to doing for her?”
Known limitations
MCP tool calls may time out for very large stores (100+ entities in one call).
Workaround: Batch into groups of 20–50 entities per store call.
Neotoma runs locally — data is not synced across machines by default.
Workaround: Use the remote HTTP transport or deploy Neotoma as a remote MCP server for multi-machine access.
Schema evolution is additive. Removing fields requires a major version bump.
Workaround: Plan schemas with future fields in mind. Use flexible entity types for exploratory data.
Start with evaluation, see the install guide for more options, MCP reference for MCP setup, CLI reference for terminal usage, and agent instructions for behavioral details.