Codex Desktop compaction requires unavailable notes tool, loses checkpoint, and repeats token-heavy work

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop; the About-dialog version is not exposed to the agent. The bundled CLI reports codex-cli 0.150.0-alpha.8.

What subscription do you have?

ChatGPT account-backed desktop session; the exact tier is not exposed to the agent.

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Codex Desktop injects a mandatory context-compaction protocol that requires the agent to write a checkpoint with a notes tool and recover it with history, but neither tool is present in the available tool surface. When the context is exhausted, the runtime still permits/requires new_context, so the active context is discarded without a checkpoint.

The next context receives no working summary. In this observed task, the agent fell back to reading the saved transcript, but large tool records were skipped or truncated. It therefore repeated GitHub issue and diff queries that it had already completed. Those repeated reads exhausted the next context within minutes and triggered the same loop again.

This is a deterministic mismatch between the runtime's injected compaction instructions and its provisioned tools, not merely imperfect summary quality. It wastes substantial tokens, repeats external operations, delays completion, and risks inconsistent conclusions.

What steps can reproduce the bug?

Observed thread: 01a05950-b653-7d11-a3cc-a7a9f518c2e2

1. Start a long, tool-heavy task in Codex Desktop.
2. Observe the injected context guidance telling the agent to use notes for checkpoints and history after compaction.
3. Inspect the available tools: there is no callable notes or history tool.
4. Continue until the context limit is reached.
5. The runtime instructs the agent to make exactly one notes write and then call new_context.
6. Because notes is unavailable, the agent cannot create the required checkpoint, but new_context still resets the context.
7. In the new context, observe that no checkpoint was injected. Any transcript fallback contains only a bounded/truncated view, so the agent repeats prior reads.
8. Repeated reads consume the next context and reproduce the reset loop.

In the observed task this happened twice within roughly two minutes. Immediately before the first reset, the agent searched its full tool catalog for a notes capability and found none.

What is the expected behavior?

The compaction contract and tool surface must agree. At least one of these should hold:

• notes and history are always provisioned whenever the runtime instructs the agent to use them;
• the runtime creates and injects an automatic durable checkpoint itself; or
• new_context fails closed when the required checkpoint was not successfully persisted.

A context reset must never silently discard active operational state and force repeated external reads.

Additional information

Related but broader continuity reports include #29356, #26354, and #37394. This report is narrower: it identifies the directly observable tool-contract mismatch and the resulting token-burning reset loop.

The repository-specific workaround should not be to build another compaction or transcript-recovery subsystem. This needs to be fixed in Codex's runtime/tool provisioning boundary.

Start at the Codex Desktop runtime/tool-provisioning boundary and trace how the compaction protocol provisions notes and history and invokes new_context. Reproduce the reset loop using the observed thread 01a05950-b653-7d11-a3cc-a7a9f518c2e2; done means compaction either persists and restores a checkpoint or refuses to reset when it cannot.