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.
Neotoma Codex hooks (optional)
The Neotoma Codex hooks package edits ~/.codex/config.toml to register session start, notification, and session end handlers. Codex exposes fewer hook points than Claude Code, so these focus on the most useful moments: anchoring each session as a conversation, recording notifications as timeline events, and capturing the final assistant reply as a safety net.
Install with neotoma-codex-hooks after npm install -g @neotoma/codex-hooks. MCP still handles agent-driven structured writes.
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. Use any tool, workspace, and chat context already available in this session to assess my real workflow. Avoid ad-hoc shell introspection just to profile me; if Neotoma is already installed, use `neotoma doctor --json` for status instead. Then tell me 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?”
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.