codex-agent-mem

Codex Integration

codex-agent-mem integrates with Codex using two runtime surfaces:

  1. notify for turn capture
  2. MCP stdio for retrieval

It also exposes a local FastAPI inspector for humans:

  1. /ui for project, session, turn, and observation browsing

And it can reinject compressed continuity when enabled:

  1. optional AGENTS.md sync for generated working memory when the pack is smaller than the source context

And it now exposes explicit audit and persistence utilities:

  1. provenance, health, and snapshot tools for debugging derived state without mutating raw history

And on top of that, it now supports governed memory selection:

  1. policies, inheritance links, and repair flows to keep continuity explicit instead of silently mixing memory

For low-impact Desktop and long-running hosts, v1.0 also adds:

  1. read-only MCP mode, profile-based tool surfaces, compact responses, lazy SQLite initialization, pack-hash reuse, runtime heartbeat diagnostics, optional telemetry, and an optional local daemon/stdio bridge

Capture flow

Retrieval flow

At 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.

Generate the config snippet

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:

The 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:

and 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.

MCP tool approvals

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.

Windows note

Use single-quoted TOML strings so backslashes stay literal.

See:

POSIX note

On macOS and Linux, prefer:

codex-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.

Optional HTTP ingest

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.

MCP lifecycle note

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.

Codex Desktop lifecycle note

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:

What codex-agent-mem does about it:

Optional daemon mode

Stdio 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:

Current limits