Codex may be moving away from repeatedly compressing long conversations and toward a memory design built around context awareness, handoff notes, and searchable history.
A new _context tool has appeared in the Codex codebase. According to the article, it gives the agent visibility into how much context space remains, which changes the job from continuously compressing prior dialogue to understanding when the current window is close to full. Taken together with newly added work annotations and history-query functions, the changes suggest Codex CLI may be preparing a new memory mechanism for long-running tasks: when the context window is nearly full, it would switch to a fresh window, leave notes before the handoff, and retrieve full prior records later if needed.
In that framing, Codex would be adding a form of external memory. When one window runs out of room, the agent carries forward handoff material into a new session, while the previous chat remains intact as an archive that can still be queried for missing details.
The article says users on X reacted strongly to the possibility, reflecting frustration with long AI sessions that lose track of prior instructions or revive paths that had already been ruled out.
Why repeated compaction can blur long tasks
Codex previously relied on compaction, or context compression, and the article argues that the method has a core weakness: compression is hard to make lossless.
It uses a Sherlock Holmes analogy. Imagine reading a novel and, after every 50 pages, writing a one-page summary and discarding the original text. The first summary may still preserve the key characters, the case, and the main clues. After several rounds, though, a detail that looked irrelevant at the time may disappear entirely.
For a coding agent, that missing detail could be a special user instruction, a terminal error message, the reason a function cannot be modified, or the explanation for why a team had already rejected plan B.
That is the problem. A summary may retain the fact that plan B was rejected, while dropping why it was rejected. Hours later, when the environment changes, the agent may see plan B again and start trying it from scratch.
The article says this is not just a theoretical concern. In Codex’s public codebase, users had already reported cases where compaction made the task background less clear and caused prior work to be skipped.
A user identified as Nico found that, compared with GPT5.5 and 5.4, compressed data in version 5.6 showed lower fidelity. He had originally asked ChatGPT to look through the Codex CLI repository for a way to let a large model understand its own context state. Following the code led him into what the article describes as a rabbit hole, where he found signs that Codex was preparing a new context-management approach.
Still, as of publication, OpenAI’s official documentation continued to list compaction as the context-management mechanism for long tasks, and GPT-5.6 still supported and used compaction. The article therefore says the more likely reading is that Codex CLI is preparing a shift or testing one, rather than that the feature has already been rolled out across the board.
The three parts of the proposed design
The article breaks the new approach into three parts: hard context-window switching, work notes, and historical record queries.
The first is a hard switch between windows. When the active context approaches its limit, Codex CLI would stop trying to preserve the appearance of one continuous ultra-long conversation. Instead, it would end the current phase and continue inside a clean new window.
That can sound like deliberate forgetting. The article argues it is closer to an engineering handoff. No engineer carries a project lasting months entirely in memory. When someone else takes over, what matters is a clear handoff document: the current objective, what has been completed, which methods were tried, which options failed, and what should happen next. Work notes would fill that role.
The second piece is historical lookup. A handoff document will never capture every detail, but the full prior dialogue would still remain as an archive. If the agent in the new window runs into uncertainty, it could search old records for the user’s original wording, error messages, or prior discussions, instead of depending on a lossy summary alone.
Put together, memory in Codex CLI would change from one repeatedly rewritten summary into a structure made up of a current workspace, handoff notes, and searchable archives.
The difference between those two models is basic. Summary mode forces the system to decide, at the instant of compression, which pieces of information might matter later. Retrieval mode lets the system wait until a real problem shows up, then determine which past material is relevant to the present moment.
If a handoff note misses a detail, the original record may still allow the agent to recover it.
If the mechanism works well, the most direct effect would be that users no longer need to keep telling the AI that something has already been discussed. The article also says it could cut hidden waste, including lost time, token consumption, and even secondary damage to code that was already correct.
It is not a universal fix, though. Notes can be wrong. They can miss important constraints. And an agent may fail to realize that it should query the archive in the first place. The real test, the article says, is whether Codex CLI can use these tools at the right time.
What _context changes
One easily overlooked but potentially central change in this design is the new _context tool.
Its job is to let Codex understand its own context usage, including how much room remains in the active window.
Without that signal, the older system would keep working until compression was triggered in the background. With _context in place, the model gets a chance to sense the state of its remaining capacity ahead of time and act accordingly.
If _context sees plenty of room left, the model can keep exploring. If the window is nearing its ceiling, _context can effectively hit the brakes, prompting the model to narrow its scope, settle current conclusions, write down the key information as notes, and prepare handoff material for the next conversation round.
The article compares it to a fuel gauge in a cockpit. A gauge does not make the vehicle travel farther on its own, but without one, the driver has a much weaker sense of when to press on and when to look for a refueling stop.
Seen that way, _context is more than a convenience feature. It adds a basic form of context self-awareness to the agent, allowing it not only to carry out a task, but also to manage the cognitive resources the task depends on.
Not a first for Codex
The article also stresses that the idea did not start with Codex.
Nico said, 「AmpCode tried this long ago, and user feedback has been quite good!」
The developer community had already explored a range of manual workflows. Some users have agents continuously update a plan.md file or a progress file during a task. Others ask the model to generate a handoff prompt when the window is close to full, then clear the chat and paste that prompt into a new session. Some explicitly save a work log for every context-window switch.
All of those workflows rest on the same assumption: instead of pretending an agent has one infinite, continuous memory, it may be better to split work into stages and establish explicit handoff points between them.
What may set Codex CLI apart is automation. According to the article, it would not need the user to decide whether the context is full. It could read the remaining capacity itself, decide when to organize notes, and determine what information should be added before moving into a new window.
Memory management versus ever-larger context windows
Over the past two years, large model providers have pushed hard on context-window size. The race moved from hundreds of thousands of tokens toward the million-token range, with vendors competing over which model could hold more information at once. The ability to remember more in one pass became a central marketing claim.
The direction exposed by these Codex changes points somewhere else. An agent may not need to keep everything in its head all the time. It can also be taught to take notes, then open a fresh notebook when the current one is close to full.
If the mechanism is eventually implemented, the article argues, Codex may reshape more than just the underlying path of model memory. It may also shift the standard for what reliable AI memory means: not never forgetting, but knowing where to look when something has been forgotten.
For teams and developers building agents, that may be a signal to revisit their own architecture.
The piece was published on the WeChat public account Quantum Position, with authorship attributed to 「关注前沿科技」, and republished by MarsBit.