Two theories of memory.
Codex and Claude Code chase the same goal — an agent that remembers — and arrive at almost opposite shapes. One builds a processing pipeline with a ledger; the other curates a library of human-readable files.
Neither is wrong. They optimize for different things, and the most interesting system isn't either one — it's what you get by stealing the best of both. Background reading: the Codex teardown and the Claude Code teardown.
Pipeline + ledger
Machine-processed. Extract → gate → consolidate, each step a tracked, retryable job. SQLite working set, git output.
File hierarchy
Human-read. CLAUDE.md instructions loaded at start + a memory directory recalled by relevance. All plain Markdown.
Processed vs. read.
Every difference downstream flows from one split: who is the primary consumer of the memory?
Codex builds memory for a worker to process — so it gets a pipeline, a promotion gate, and a job ledger, but its durable output is the only part a human really touches. Claude Code builds memory for a human to read — so it gets legible files, a hierarchy, and version control, but no leased workers grinding in the background.
Codex asks "how do I reliably turn sessions into durable knowledge?" Claude Code asks "how do I keep memory something a person can read, trust, and edit?" Both questions are right.
Dimension by dimension.
Ten axes. Green marks the clear strength on each row.
| Dimension | Codex | Claude Code |
|---|---|---|
| Substrate | SQLite working set + git output | Plain Markdown files |
| Primary reader | A worker / pipeline | A human |
| Structure | Schematized — frontmatter + typed sections | Free Markdown + light frontmatter |
| Promotion gate | Yes — selected_for_phase2 | No explicit gate |
| Reliability ledger | Yes — leases, retries, watermarks | No — best-effort |
| Provenance | None | Light type tag only |
| Human-readability | Output only (MEMORY.md) | Everything — read & edit it all |
| Version control | Output is git | Native — lives with the code |
| Recall | Recency-indexed | Relevance (memory tool) |
| Always-on cost | Low — pulled on demand | CLAUDE.md is always in context |
| Portability | Single-vendor, one disk | Single-vendor, one disk |
| Scope partition | None | Hierarchy ≈ scope (enterprise→project) |
The shared loss is the last-but-one row: neither is portable. Both lock memory inside one harness on one machine — which is the whole reason to build a layer that belongs to neither.
Pick the right tool for the job.
You need durable, reliable distillation
- High volume of sessions to compress into lessons
- Background work that must survive crashes
- A curated layer separate from raw history
- Machine-to-machine portability of "what was learned"
You need legible, governed conventions
- Team rules that belong in the repo and in PRs
- Memory a human must audit and trust
- Layered scope: org → user → project
- Fast hand-editing and quick
#additions
Steal from both.
A portable memory layer doesn't pick a side — it takes the spine from each and adds what neither has.
from CODEX pipeline · promotion gate · job ledger (leases/retries) from CLAUDE CODE human-readable artifacts · scope hierarchy · git-native net-new provenance (fact/inference) · pgvector recall · MCP interface ─────────────────────────────────────────────── = one store, every agent, owned by you
Codex gives the reliability and the gate. Claude Code gives the legibility and the scope. Provenance, semantic recall, and an MCP front door make it neutral and trustworthy. That's the portable-memory vision — and the Fleet Memory v2 proposal is the first concrete build of it.