Add codex platform support for Codex CLI memory capture (read now, write when hooks land)

[github-actions[bot]]

Originally posted as issue #1270 by @ComradeExe
#1270

Summary

I use both Claude Code and OpenAI Codex CLI heavily - Claude Code for complex
agentic work, Codex for its generous context limits and strong reasoning on
large tasks. Having shared persistent memory between the two would make them
genuinely complementary rather than siloed.

Current State

claude-mem already supports claude-code and cursor platforms. Codex CLI
supports MCP servers natively (via config.toml), so Codex can already READ
from claude-mem today by connecting to the mcp-server.cjs MCP server.

The gap is WRITING. Codex CLI does not yet have a PostToolUse or SessionStart
hooks system equivalent to Claude Code's. It only has a notify config that
fires on agent-turn-complete. This means automatic per-tool observation
capture isn't possible yet.

What I'm Requesting

1. A codex platform for the raw hook — similar to how cursor is a
   supported platform. The worker already accepts hook raw observation but
   needs to know the expected JSON input format Codex should send (message
   history format, tool call format, etc.) so that observations actually get
   saved rather than filtered out.

2. A notify-compatible endpoint — since Codex's notify fires on
   agent-turn-complete with a JSON payload (thread-id, last-assistant-message,
   input-messages, cwd), the worker could accept this payload and generate a
   session summary observation from it. This would give Codex at minimum
   end-of-turn memory capture today, without waiting for full hooks support.

3. Documentation — a section in the README showing how to configure Codex
   CLI's config.toml to point at the MCP server and use the notify hook.

Why This Matters

Claude Code excels at long agentic sessions, hooks-driven automation, and
complex multi-step work. Codex CLI excels at large context tasks, has a more
generous plan, and reasons well about big codebases. Used together they cover
each other's gaps. Shared memory via claude-mem would make the combination
dramatically more powerful — work done in a Codex session would be available
in Claude Code and vice versa.

Technical Details

• Worker is already running as a local HTTP server (default port 37777)
• hook raw observation already returns exitCode 0 when called
• The worker's AI filters out low-value content, so the format of the JSON
  payload passed on stdin matters for whether observations are actually saved
• Codex's notify payload includes: type, thread-id, turn-id, cwd,
  input-messages, last-assistant-message

[sjh836]

oh-my-codex(omx) supports hooks

[gudzenkov]

Been looking for unified backend for session memory/learnings/knowledge for a while.
claude-mem is the best so far in terms of the capabilities, but locked to the single harness only, which is quite restrictive, given that most of engineers use several models/harnesses across variety of tasks.

Looking forward to seeing this feature in the roadmap!