Daily Edition Sources +3

When a Context Limit Drops the User’s Turn

OpenClaw found a required Codex compaction preflight treating an intentional no-op as a fatal failure—so an overlong session could lose the incoming user turn before the model ever answered.

A rough paper diagram shows a user turn reaching required preflight, a crossed-out successful-but-uncompacted response, a circled Codex compaction request, and a stale-binding fallback card.
Diagram Punka required preflight cannot mistake an uncompacted no-op for recovery.
repos openai/codex + openclaw/openclaw evidence
3 source signals 2 repos commit 16cde04
Evidence: commit 16cde04 / August 17, 2026 / Daily Edition
Open Edition Evidence below

OpenClaw issue #119971 records a concrete failure: a Codex app-server session crossed its budget, emitted an intentional “app-server owns automatic compaction” result, and then rejected the user’s message before a model call ran. That is the wrong way for a long conversation to become difficult. It should trim what it can, preserve useful state, and keep the next message moving—not drop the turn.

That sequence matters because the system had decided compaction was required. A result shaped like success—ok: true, but compacted: false—was only safe if something else had already done the recovery. Here, the reply-preflight path had not asked Codex to perform a non-manual native compaction, then treated the resulting skip as a hard failure. The public issue traces the mismatch from the budget gate to the user-facing error.

A name for the handoff

The fix in PR #120197 does more than bless the skip. It labels the request required_preflight, routes it through OpenClaw’s private native-compaction bridge, and asks the Codex app server to begin compaction. The accompanying commit and tests make the distinction visible: a required preflight records its origin and calls the native thread-compaction endpoint; a binding that changes underneath it becomes an explicit stale-binding failure so the existing context engine can take over.

That is a more demanding rule than “don’t error on a no-op.” If a preflight is mandatory, quietly accepting an uncompacted thread only hides the next failure. The patch also keeps its escape hatch narrow: the special recovery is for missing or stale Codex bindings in this preflight route, not a general permission to dissolve model locks or treat every skipped compaction as harmless.

The next signal is a shipped path

For an operator, the useful question is now precise: does the installed OpenClaw build contain this required-preflight route, and can a disposable Codex app-server session cross its context budget without discarding the next message? The evidence here is a public issue, PR, main-branch change, and focused tests—not a release receipt or a fleet reliability study. Watch for the version that carries the patch and for an independent end-to-end report; until then, “automatic compaction” is still a contract worth checking at the handoff.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateAugust 17, 2026
LaneDaily Edition
Confidence78%
Sources3
Reposopenai/codex, openclaw/openclaw

Primary Evidence

Evidence Limits

  • These are public issue, PR, main-branch code, and tests. They do not prove a released build contains the fix, measure how often the failure occurs outside the reported case, or establish long-context reliability for other harnesses.
  • Watch for a release note or independently reproducible operator report that identifies the shipped version and confirms the required-preflight path with a real Codex app-server session.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.