codex-agent-mem integrates with Codex using two runtime surfaces:
notify for turn captureIt also exposes a local FastAPI inspector for humans:
/ui for project, session, turn, and observation browsingAnd it can reinject compressed continuity when enabled:
AGENTS.md sync for generated working memory when the pack is smaller than the source contextAnd it now exposes explicit audit and persistence utilities:
And on top of that, it now supports governed memory selection:
For low-impact Desktop and long-running hosts, v1.0 also adds:
agent-turn-completecodex_agent_mem.codex_notify normalizes the payloadsession_summary, decision, and operational-state observationsAGENTS.md is updated in the working directorymem_searchmem_getmem_recentmem_session_listmem_scope_resolvemem_bootstrap_contextmem_project_briefmem_open_workmem_completion_checkmem_recent_changesmem_scope_guardmem_context_packmem_provenancemem_healthmem_health_runtimemem_snapshot_listmem_note_createmem_snapshot_createmem_snapshot_restoremem_policy_listmem_policy_validatemem_policy_addmem_policy_removemem_inheritance_listmem_inheritance_addmem_inheritance_removemem_repair_proposemem_repair_applyAt task startup, prefer mem_bootstrap_context(project_key, ...) when the
host can provide a chat title, thread hint, cwd, repo path, or mentioned files.
It is read-only and refuses to treat a project-wide container pack as active
context when the stored memory has several candidate lanes. If the scope is
already explicit, call mem_context_pack(project_key, session_id=...).
mem_context_pack also supports budget=auto, so the runtime can select the smallest fitting reinjection profile instead of always forcing one fixed budget.
In v1.0, mem_context_pack also returns a stable pack_hash and accepts known_pack_hash. If the generated continuity pack did not change, the server can return a compact not_modified=true response instead of resending the full pack.
codex-agent-mem-bootstrap-codex --db-path "$HOME/.codex_agent_mem/codex_agent_mem.db"
codex-agent-mem-bootstrap-codex --db-path C:\Users\YOU\.codex_agent_mem\codex_agent_mem.db
The generated config uses:
notify[mcp_servers."codex-agent-mem"]--idle-timeout-seconds for defensive stdio cleanup--profile for profile-aware tool surfaces--response-mode for compact, balanced, or verbose MCP text responsesapproval_mode = "approve" for the configured MCP toolscodex_agent_memThe default helper emits the full profile. That keeps writable continuity
available, including manual notes, snapshots, governance, repairs, and restore
tools. Review the approved tools before pasting if you want a narrower surface.
For an explicit retrieval-only audit/debug profile, generate:
codex-agent-mem-bootstrap-codex --mcp-profile minimal --mcp-read-only
codex-agent-mem-bootstrap-codex --mcp-profile minimal --mcp-read-only
That exposes only:
mem_session_listmem_scope_resolvemem_bootstrap_contextmem_context_packmem_open_workmem_completion_checkmem_health_runtimeand disables mutating MCP tools.
--sync-project-doc is now opt-in. Add it to notify only if you want automatic AGENTS.md reinjection in the working directory.
The generated snippet also marks the configured MCP tools as:
approval_mode = "approve"
That matters for non-interactive Codex runs such as codex exec, where MCP tool prompts can otherwise be cancelled before returning data.
Use single-quoted TOML strings so backslashes stay literal.
See:
On macOS and Linux, prefer:
$HOME/.codex_agent_mem/codex_agent_mem.db for the local database pathcodex-agent-mem-bootstrap-codex --db-path "$HOME/.codex_agent_mem/codex_agent_mem.db"
When editing ~/.codex/config.toml manually, use the installed command paths from your environment instead of Windows-style Scripts\\ paths.
The default and simplest path is direct DB ingestion through notify.
An optional HTTP wrapper also exists:
That path is useful only if you explicitly want notify -> HTTP -> local API.
The current transport is stdio. That means one MCP process per host connection is expected; this integration does not claim a singleton daemon. codex-agent-mem now adds an idle timeout, signal-aware shutdown, runtime diagnostics, and explicit SQLite cleanup so unused or orphaned stdio instances exit more defensively.
Current evidence points to a host-side lifecycle problem in long-lived Codex Desktop sessions rather than a single MCP being the sole root cause.
Observed pattern:
codex exec --ephemeral with the same global MCP config finishes cleanlyWhat codex-agent-mem does about it:
--sync-project-doc opt-in instead of defaultmem_health_runtime--profile minimal --read-only for retrieval-only Desktop checksinitialize, tools/list, and mem_health_runtimeknown_pack_hash matchesStdio remains the default and most compatible transport.
If a host repeatedly opens MCP stdio connections, you can run a local daemon:
codex-agent-mem-daemon --db-path "$HOME/.codex_agent_mem/codex_agent_mem.db" --profile full --auth-token YOUR_LOCAL_TOKEN
Then point the stdio bridge at it:
codex-agent-mem-mcp --daemon-url http://127.0.0.1:37773 --daemon-token YOUR_LOCAL_TOKEN --db-path "$HOME/.codex_agent_mem/codex_agent_mem.db"
On Windows PowerShell:
codex-agent-mem-daemon --db-path C:\Users\YOU\.codex_agent_mem\codex_agent_mem.db --profile full --auth-token YOUR_LOCAL_TOKEN
codex-agent-mem-mcp --daemon-url http://127.0.0.1:37773 --daemon-token YOUR_LOCAL_TOKEN --db-path C:\Users\YOU\.codex_agent_mem\codex_agent_mem.db
The public 1.0.x daemon accepts only loopback bind hosts (127.0.0.1, localhost, or ::1). The optional bearer token is recommended when the daemon is kept alive, but it is a local safeguard only; it does not replace TLS, OAuth, hosted authentication, or a remote access-control layer.
That does not claim to fix the host bug. It reduces the blast radius and makes the MCP easier to audit.
For the full diagnostic note and temporary mitigations, see:
1.0.x line