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!

[xiaojiou176]

Hi! I prepared two upstream-ready branches for this work, but GitHub is currently blocking PR creation because the repository only allows collaborators to open pull requests.

1. Codex integration PR
   https://github.com/thedotmack/claude-mem/compare/main...xiaojiou176:feat/codex-hook-first-v2?expand=1

2. Runtime reliability PR
   https://github.com/thedotmack/claude-mem/compare/main...xiaojiou176:fix/runtime-reliability-v2?expand=1

Both branches were sculpted in clean worktrees, split into bounded commits, and re-verified before push.

If useful, I can also provide request-pull summaries / patch bundles. If you prefer, please either:

• add xiaojiou176 as a collaborator temporarily, or
• temporarily relax the PR restriction so I can submit the PRs normally.

Happy to adjust scope if you’d rather review one of the two first.

[Stemae90]

@thedotmack this would be great, heavily invested in Claude-mem and want to switch to Codex now, please help.

[NoRain211]

I also put together a Codex lifecycle hook branch, then found this discussion and saw @xiaojiou176's work here.

My branch:
https://github.com/NoRain211/claude-mem/tree/feat/codex-lifecycle-hooks

Compare:
main...NoRain211:claude-mem:feat/codex-lifecycle-hooks

The angle is similar to the original "read now, write when hooks land" request, but using current Codex lifecycle hooks rather than only notify/transcript capture.

It implements:

• claude-mem codex-hook entrypoints for SessionStart, UserPromptSubmit, PostToolUse, Stop, and dispatch
• Codex hook payload normalization into the existing claude-mem hook/observation pipeline
• platform_source = "codex" persistence
• per-tool observation capture through the existing pending queue
• Stop-hook summary enqueueing without forcing Codex continuation
• transcript ingestion retained as fallback/backfill
• direct hook config management:
  • npx claude-mem codex install-hooks --scope user
  • npx claude-mem codex install-hooks --scope repo
  • npx claude-mem codex hooks-status
  • npx claude-mem codex remove-hooks --scope user
  • npx claude-mem codex remove-hooks --scope repo
• docs for Codex native memory coexistence and troubleshooting

Verification:

npm run build
git diff origin/main --check