Build1 distinct publisher3 min readPublished
A code reading of Codex's cross-session memory finds models writing the guidance and runtime code deciding eligibility, expiry and deletion. The retention signal is citation count, not truth.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The feedback loop is where the split gets expensive. Memory citations carry rollout IDs, and when Codex emits one, runtime code increments usage counts and timestamps on the matching Phase 1 records; later consolidation passes prefer evidence that has been used frequently and recently [7]. The ranking signal, in other words, is agent behaviour. A build command that stopped working three weeks ago keeps earning its place every time an agent cites it, while the corrected version enters with a usage count of zero.
Nothing in the described pipeline checks a remembered fact against the repository as it stands. Phase 2 receives selected evidence plus a git workspace diff [8], and the prompts ask the models to merge new evidence, rewrite stale guidance, preserve uncertainty and drop claims whose evidence has disappeared [9]. That is judgement applied to what the extraction stage happened to surface, not verification. What the working agent actually sees is narrower still: a bounded `memory_summary.md` injected into developer instructions, after which the model searches `MEMORY.md` and opens one or two supporting summaries or skills [11].
If you spot the stale fact yourself, the route back is indirect. According to the analysis, a direct request can produce an append-only ad-hoc note, but only when dedicated memory tools are enabled or the active permission profile separately permits the write, and the note changes nothing until the next consolidation pass interprets it and regenerates the artifacts [10]. That is two conditionals and a scheduler between "this command is wrong" and the file your next session reads. Dispatch is not on session start either; the author notes memory work is triggered only after a fresh turn [15].
Count the deletion paths in the source and you get seven: an extraction dropped after a later no-op, summaries falling out of the selected set, the consolidation agent removing unsupported guidance, pruning of unused database rows, expiry of extension resources, memory attached to a deleted thread, and a full reset of the store [14][5]. Not one of them fires because a fact became untrue. Six are plumbing and set membership; the seventh is a model being asked to notice. A wrong-but-cited fact satisfies none of the conditions, which is the mechanism by which last month's guidance survives into next month's sessions.
Two more things worth holding onto from this reading. First, the semantic work is a two-model background pipeline, one model extracting reusable material per eligible rollout and a second consolidating into a global file-based workspace [16], so the artifact your agent trusts was authored by a model you did not watch write it. Second, `AGENTS.md`, session persistence and compaction remain separate systems, and the analysis puts team rules squarely in explicit instructions [12]. That division is the practical control surface here: anything you cannot afford to have quietly rewritten does not belong in the pipeline that rewrites things.
Ranked by verification strength, evidence, and original report placement.
A dev.to analysis pinned to OpenAI Codex commit 8444cf63b50a8a88521e0d2970d49f659b48eac7, checked on August 25, 2026, concludes that Codex has a genuine cross-session memory subsystem whose behavior is split between model judgment and deterministic lifecycle code.
Models decide what a rollout means and how durable guidance should be rewritten.
Runtime code decides which rollouts are eligible, which evidence remains in the working set, when old records are deleted and when the consolidation model may run; Rust and SQLite code choose candidates, enforce leases, rank inputs, prune old rows and synchronize files.
With local memories enabled, Codex can autonomously add, modify, merge and remove persistent memory without a user approving each write.
Forgetting has several independent mechanisms rather than one delete operation: deleting an old extraction after a later no-op, dropping rollout summaries that leave the selected set, asking the consolidation agent to remove unsupported guidance, pruning unused database rows, removing expired extension resources, forgetting memory attached to a deleted thread, and resetting the entire memory store.
The feature is marked stable in that source tree but remains off by default, so the analysis describes implemented behavior rather than behavior every Codex user is currently receiving.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and commit-pinned, but single-source and unverified
The claims are unusually concrete for this kind of story - a named commit hash, a check date, named artifacts (stage1_outputs, memory_summary.md, MEMORY.md), explicit defaults and enumerated deletion paths - which raises evidentiary quality above generic reporting. But every claim traces to one author's reading of one source tree published on a developer blog, with no vendor documentation, repository citation the reader can diff, release note or second reviewer in the cluster, and the supplied body is truncated mid-section. That caps evidence below the midpoint.
Implemented and stable in-tree, but default-disabled with no usage data
Adoption evidence is limited to code state: the feature exists and is marked stable at the pinned commit, with conservative shipped defaults for lookback, input caps and 30-day pruning. It is off by default, and the source discloses no enablement rate, deployment count, customer usage or benchmark. Low value reflects real implementation with no demonstrated user uptake.
Mildly overstated by framing, hedged in the body
The body is notably disciplined: it pins a commit, states the feature is off by default, and separates model judgment from runtime scheduling instead of claiming emergent agent memory. The overstatement is in framing and reach - 'remembers by popularity' and 'who decides what your agents forget' imply an active, widespread governance problem, while the underlying situation is default-disabled code read once by one author with zero adoption evidence. Small positive gap, driven by framing and single-source provenance rather than by inflated technical claims.
No disclosure available
The cluster provides only publisher metadata (a dev.to post by an individual author) with no statement of the author's relationship to OpenAI, no funding, employment, affiliate or product disclosure, and no indication of who commissioned or reviewed the analysis. Inferring an incentive level from publisher type alone would be guessing, so this dimension is left unmeasured.
Internally coherent single-source reading
Confidence is moderate-low. In favour: mechanism-level specificity, an explicit scope caveat, and internal consistency between the pipeline description, defaults and forgetting paths. Against: one publisher, one author, no independent replication or vendor confirmation, a truncated body, and derived elements (such as the count of seven forgetting paths and the model-versus-code authority split) that depend on the author's interpretation of code the reader cannot inspect from the cluster.
product
Four leaderboards, four denominators: what you buy when you standardize on a coding agent1 distinct publisher
build
Codex learns to click: the coding agent stops typing patches and starts operating the machine1 distinct publisher
build
Claude Code now outruns Copilot roughly two to one in JetBrains' survey of 15,000 developers1 distinct publisher
build
OpenCode has no memory subsystem. It has three mechanisms that fail differently1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026