Claude Code and Codex can use the same persistent memory store without pretending to be one application. Each tool keeps its own sessions, model behaviour, and execution environment. The goal is a unified read: when either agent starts, it can surface relevant history written by both platforms.
The Architecture
- One shared claude-mem backing store.
- Each session tagged with its originating platform.
- Separate live sessions for Claude Code and Codex.
- A merged startup timeline containing observations from both platforms.
- Optional explicit filtering when a platform-specific view is needed.
Problem One: Read-Side Filtering
The startup-context handler automatically applied a platform filter. Claude Code therefore saw only Claude Code history, while Codex saw only Codex history. Both tools were writing to the same store, but the automatic read path hid half of it.
The fix removed the automatic platform filter from merged startup context while preserving deliberate platform-specific queries.
Problem Two: Write-Side Mislabeling
Codex hook configuration passed the wrong platform name for session start, prompts, tool use, and stop events. Codex activity was stored as if Claude Code had produced it. That made platform-specific diagnostics unreliable and could hide sessions from filtered views.
The fix changed the Codex hook invocation so new records are tagged as Codex. Worker compatibility was checked, then fresh sessions were used to verify correct writes.
End-to-End Verification
Verification required more than inspecting configuration files:
- Start fresh Claude Code and Codex sessions so startup hooks fire.
- Confirm each platform writes its own identity.
- Confirm completed sessions receive persistent memory identifiers.
- Start a new session on the opposite platform.
- Verify that its startup context contains observations written by the other agent.
The acceptance test passed when Claude Code surfaced Codex-authored observations during startup.
An Important Timing Lesson
Active memory jobs can temporarily appear incomplete because session identifiers are captured asynchronously after the memory-generation subprocess responds. Checking while summarisation is still running can look like data loss. The correct check is performed after job completion, using both database state and worker lifecycle evidence.
Durability Risk
Local patches inside plugin caches are not durable. A plugin update may install a fresh versioned directory and silently restore the old behaviour. A production-quality fix belongs in the upstream source or in a supported user-level extension point, not as a permanent manual patch inside generated cache directories.
Operational Lessons
- Shared storage does not guarantee shared visibility.
- Read-path and write-path bugs can exist independently.
- Platform identity must be explicit at every hook boundary.
- Fresh-session tests matter because resumed sessions may not run startup hooks.
- Asynchronous state must be checked after completion.
- Configuration inspection is not enough; cross-platform retrieval is the real acceptance test.
- Cache patches require an upstream durability plan.
Result
Claude Code and Codex remain independent coding agents, but both can now contribute to and read from one merged memory history. This reduces repeated investigation across tools while keeping platform origin visible for debugging and audit.