Review: Codex Has No Memory
An engineer’s review of OpenAI Codex 5.3, its strengths and limits, plus a forward look at Claude’s memory claims.
Codex 5.3 is powerful but fundamentally stateless, which breaks assumptions in mature engineering orgs.
Context compaction isn’t a bug, it exposes reliance on implicit institutional memory.
For CIOs/CTOs, workflows must be redesigned around explicit context re-hydration.
If you’re not technical, this post may not be for you.
But if you work with a CIO, CTO, or senior engineering leader, it absolutely is for them.
Please forward it.
This is one of those “you need to see this” reads.
Over the last few days I’ve been using OpenAI’s Codex 5.3 not as a curiosity, not as a toy, but the way I run real engineers:
Agile sprints
Architecture Decision Records (ADRs)
Backlogs and tasks
Documentation outside of the tool that actually matters
And then something predictable happened: compaction arrived.
Context compacted is holy awful
It about forgets almost all the key details we’ve been talking about and I have to re-explain it instructions and remind it how to do things. And it keeps auto compacting frequently, and the context % left when it does that is still low. Absolutely terrible.
- Reddit - r/codex - Blankcarbon
Nothing crashed. Nothing errored. No elephant-in-the-room warning messages. The model just … stopped behaving like it remembered the project.
Important constraints blurred. Decisions we’d agreed upon earlier reappeared as options. Rejected ideas quietly returned.
At first, you assume it’s a product flaw.
It’s not.
It’s a misalignment between how organisations think about memory and how these models actually operate.
OpenAI Codex 5.3: Powerful, Focused, Stateless
From a pure execution perspective, Codex 5.3 (OpenAI’s latest coding agent) is impressive.
It parses natural language and produces deep code changes autonomously. It interfaces with terminals and tools. And it’s fast compared to previous versions.
But its context window, and a compression-based approach to old content, means it only retains a temporary view of the recent conversation. Once that window is full, older context is summarised or compressed, loosely and heuristically.
What you discover quickly when running a real project is this:
Codex does not carry institutional memory.
Not bad memory.
No memory.
That’s not negligence, it’s design.
Why This Matters to Real Engineering Teams
When we think of engineers, we think of people who hold context:
Why a decision was made
What failed last time
Which constraints are political, not technical
What not to propose again
Human teams compound institutional knowledge through documentation, culture, and repetition.
Codex does not.
It only operates within a bounded context window that eventually compacts. Once that compaction happens, the model’s coherence with project history diminishes.
This breaks two assumptions simultaneously:
The AI will remember project history.
You only need to introduce context once.
Both assumptions are false in practice.
For engineering leaders, that matters.
The Leadership Challenge Codex Reveals
Here’s what most CIOs and CTOs don’t realise at first:
You cannot treat Codex like a long-tenured engineer.
Codex is better analogised as a world-class contractor:
It needs context reintroduced every time.
It won’t remember why constraints were decided.
It won’t carry forward patterns or past rejections unless they are restated.
The friction many teams feel with GenAI isn’t a model failure.
It’s a workflow assumption failure.
How Senior Tech Leaders Should Adapt
This section is the part to share with your engineering leadership.
1. Chat Is a Session, Not a Workspace
Don’t rely on a thread to carry meaning.
Treat each session as ephemeral.
2. Architecture Must Be Explicitly Re-Introduced
Your ADRs, constraints, decisions, paste them back in.
If it matters, restate it.
3. Treat Compaction as a Hard Boundary
Codex doesn’t “forget,” it compresses and resets context.
Assume a reset.
Rehydrate context.
Proceed.
4. Assume Zero Memory Between Sessions
This is a tough cognitive shift.
If Codex has to know it, you must restate it.
No exceptions.
5. Deploy Codex Where It Excels
It’s great at:
Well-scoped execution
Explicit constraints
Deterministic outputs
It’s weak at:
Implicit context
Political decisions
Preserving project history
A Side Note on Claude and Memory (Future Research)
While this piece stays focused on Codex 5.3, it’s worth noting that Anthropic’s Claude models are positioning themselves differently.
Claude systems (e.g., Claude Code, Claude Opus family) claim extended memory and very large context window support, up to ~1 million tokens in enterprise versions, allowing them to reference large codebases and project context in a single session.
Some community reports and projects suggest Claude tools may persist project context across sessions or build project memory artifacts, though those features are still emerging and not broadly evaluated in real engineering workflows yet.
This is an area worth tracking, but my experience with Codex highlights a more fundamental point: even when models can remember context, you still need explicit practices to make that useful in an organisational setting.
The Real Takeaway
OpenAI Codex 5.3 doesn’t lack memory because it’s incompetent.
It lacks institutional memory because it was never engineered to replace organisational knowledge.
That’s something leaders need to wrap their heads around.
Codex excels when tasks are well-bounded and constraints are explicit.
It falters when workflows assume context persists.
Your job as a CIO/CTO isn’t to find AI that remembers everything.
Your job is to design teams and workflows where memory is externalised, explicit, and restatable, so that any AI, no matter whose model, can plug in and contribute reliably.
Codex isn’t forgetful.
It just requires you to lead in a new way.
If this resonated but felt technical, forward it to your CIO or CTO.
They’ll know exactly why it matters.