Long Codex tasks can spend a surprising amount of time revisiting work that has already converged.
The agent has inspected the relevant files, run tests, ruled out several paths and narrowed the problem. Compaction happens. Work continues, but the next stretch may begin with the same files being reopened and the same decisions being reconstructed.
A larger context window gives the agent more capacity, while compaction lets a long conversation fit back inside that capacity. Context Canvas handles a different part of the job: it keeps a small external record of where the work has reached and points back to the evidence needed to continue.
Where the repeated work comes from
OpenAI’s description of the Codex agent loop explains that conversation history and tool activity increase the input used for later inference. Once token usage crosses a threshold, Codex compacts the conversation and continues with a smaller representation. The Responses API also provides a dedicated compaction mechanism.[1]
That keeps a long loop moving. The record of what was actually changed, tested or ruled out still needs an inspectable home outside the model’s working context.
Two public Codex issues show different failure shapes around that boundary. Issue #5957 is a community bug report with a long session trace: the agent had edited several files before automatic compaction, then lost awareness of recent edits and later denied making one of them.[3] The incident is enough to separate conversation continuity from execution evidence.
Issue #16812 focuses on cost rather than memory loss. In the reporter’s own session-log analysis, essential large files were read again after compaction, followed by renewed context growth and another compaction cycle; the reported token and read counts describe that workload.[4] The recurring work looked like this:
WORK → TOOL OUTPUT → CONTEXT PRESSURE → COMPACT → REREAD → RE-DERIVE → WORK
A first read brings in new information. If the underlying file has not changed, rereading it solely because the previous conclusion disappeared from working state mostly reconstructs old context. Enough reconstruction can create more context pressure of its own.
Earlier long-context experiments, unrelated to Codex, found that models can accept large inputs without using information at every position equally reliably.[5] Capacity alone still does not decide which old information belongs in active context for the next step.
Figure 1 | A long task can survive compaction and still spend the next cycle reconstructing earlier work.
What the Canvas records
OpenAI’s June guide to long-running Codex work pushes useful memory outside the conversation. It describes message history as useful but not always sufficient for longer threads, and suggests keeping important context in material that can be opened, edited, diffed and reused.[2]
Context Canvas follows that workflow principle. It is not a built-in Codex feature. The version used here is deliberately small:
# Context Canvas
## Goal
What observable result makes this task done?
## Current state
What is complete, what is still uncertain, and where is the work now?
## Decisions
Which choices already constrain the remaining path, and why?
## Dependencies / blockers
What does the next step depend on?
## Evidence pointers
Which files, diffs, commits, test reports or artifacts support the current state?
## Next route
What is the smallest next action after resuming?The file stops being useful if it becomes a dumping ground for shell output, full diffs and test logs. The Canvas keeps the task legible; raw evidence remains in the repository, report or artifact where it can be checked again.
Anthropic’s long-horizon context engineering and harness work uses a comparable architecture: compaction is combined with structured notes and progress artifacts that persist outside the active conversation.[6][7] These sources provide comparative architecture background only; they do not describe Codex product behaviour.
Keep the shape. Keep the receipts. Resume with a route.
Open the Canvas and the current shape of the task should be visible. Conclusions should still lead to receipts, and the next action should not depend on browsing the repository until the previous route is rediscovered.
Do not add a Canvas to every task
A small edit does not need a continuity system wrapped around it. If Codex can inspect a few files, make the change, run the relevant check and finish in a short thread, maintaining another artifact adds coordination without buying much recovery value.
The extra file starts paying for itself when recovery is already part of the workload: the task is likely to cross several conversation cycles or compactions, exploration is expensive, earlier decisions constrain the remaining path, tool output is much larger than the evidence that must survive, or the work will be interrupted and resumed.
Once finding the current position again costs more than maintaining the thin map, the map has a job. Changed files and stale evidence are different. They require another look at the source regardless of whether a Canvas exists.
Resume from the next decision
The first few actions after a resume reveal whether enough task state survived.
Without a map, recovery often starts broadly: inspect the repository root, reread project documentation, check modified files, search for familiar symbols, then infer where the previous run stopped. Any one of those checks may be sensible when state has changed. Repeating the whole sequence after compaction is usually reconstruction work.
With a Canvas, recovery starts from the recorded goal, current state, decisions and next route. The agent retrieves the evidence required by that next action, revalidates anything mutable that may have changed, then continues from the smallest step that can distinguish the remaining hypothesis.
Suppose the recorded state says the failure has been narrowed to the seam between a parser and a validator, while current evidence has ruled out the storage layer. The next reads are the parser code, the latest relevant diff and the associated test evidence. Storage returns to scope only if new evidence points there.
Part 01 dealt with wandering during an investigation. Context Canvas preserves the route once that investigation has narrowed the problem, so a later context window does not have to narrow it all over again.
After compaction or a resumed thread, the behaviour is easy to inspect. If the relevant artifacts have not changed, the agent should recover its position from the Canvas, fetch the evidence needed for the next move and continue. Scanning the same files and rebuilding the same conclusions means the continuity record is missing something useful. The gap may be an empty current state, an unreachable receipt, a vague next route or evidence that has actually gone stale.
With unchanged artifacts, the check is concrete: does the run continue from the recorded position, or start rediscovering the repository?
Receipts expire with the state they describe
An evidence pointer can reference a file and section, a commit, a diff, a test report, an evaluation artifact or saved tool output. The Canvas only needs enough context to say what the evidence supports, where it lives and which state it came from.
If the next action depends on one parser test and a recent diff, retrieve those two items. A long historical log does not need to return to the prompt just because it existed earlier in the task.
Historical receipt ≠ current truth.
A test report proves what passed against the state it tested. Change the branch afterwards and the old report no longer proves that the current tree passes. Documentation, generated artifacts and external sources can go stale for the same reason.
A pointer therefore benefits from a little scope. “Focused parser tests passed against this tree state; re-run if the parser or fixtures change” is more useful than “tests passed”. It tells the resumed agent when the receipt can be reused and when revalidation is necessary, without bringing the whole test output back into context.
Figure 2 | The Canvas stores the route. Evidence stays where it can be checked again.
A stale receipt sends the agent back to the source. If the underlying artifacts are unchanged, the next action should begin from the recorded task state instead of rebuilding it from scratch.
References
- OpenAI, Unrolling the Codex agent loop, 23 January 2026. https://openai.com/index/unrolling-the-codex-agent-loop/
- OpenAI, Codex-maxxing for long-running work, 22 June 2026. This article uses the durable-thread and memory sections as official background for long-running continuity. https://openai.com/index/codex-maxxing-long-running-work/ ; whitepaper: https://cdn.openai.com/pdf/8a9f00cf-d379-4e20-b06f-dd7ba5196a11/OAI_WhitePaper_Codex-maxxing26.pdf
- OpenAI Codex GitHub issue #5957, Auto compaction causes GPT-5-Codex to lose the plot, community bug report. Used here as one observed compaction-memory failure, not as a claim about normal product behaviour. https://github.com/openai/codex/issues/5957
- OpenAI Codex GitHub issue #16812, Context compaction regression in CLI v0.118 — 2x more frequent compactions cause token usage explosion, 4 April 2026. Its figures are the reporter’s own session analysis, not an OpenAI benchmark. https://github.com/openai/codex/issues/16812
- Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024. Used only for the distinction between accepting long context and using information across that context reliably. https://transacl.org/index.php/tacl/article/view/5757
- Anthropic, Effective context engineering for AI agents, 29 September 2025. Comparative background on context curation, compaction and structured note-taking. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic, Effective harnesses for long-running agents, 26 November 2025. Comparative background on durable progress artifacts across context windows. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents