[Bug]: Codex parent wedges on delegated-result handoffs with a known 475k context window #19768

Before submitting

I searched the existing reports. This is a standalone report of my measured Codex, known-window incident, previously added to #16147 in this comment. It overlaps the handoff-delivery failure already addressed by open PR #19414; I am not claiming a new independent root cause or requesting a competing implementation. #16147's original report concerns an unknown OpenCode model window, which is different from my trigger.

Area

apps/server — context handoff budgeting and provider-turn startup

Environment / version

• Windows desktop; T3 Code Nightly installed resources dated 2026-10-12. Exact installed release/commit was not established.
• Codex parent using gpt-6.1-sol, with asynchronous app-owned delegated tasks.
• Source comparison: main at e536bfd33bc3c351997141d93790df75eeded7b9, checked on 2026-10-15. This is not the installed build's commit.

Observed sequence

This is an actual incident and source trace, not a minimal deterministic reproduction.

1. A long-running Codex parent had completed five successful native compactions; the latest was 2026-10-13T23:16:37.682Z.

2. Its last successful turn ended around 2026-10-14T02:21:43Z. Native token-count evidence and T3's persisted provider-thread contextUsage agreed on 356,824 used / 475,000 maximum tokens. The persisted usage had no autoCompactThreshold field.

3. A delegated-result wake turn failed at 2026-10-14T02:27:25.265Z with:

   Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.
   

4. Subsequent completion wake turns and ordinary user messages failed at the same gate before further native execution. A plain-language request to compact also failed as an ordinary message.

Expected behavior

An oversized pending handoff should remain recoverable without repeatedly preventing the parent from processing otherwise valid requests. Any recovery must preserve pending results and avoid silently truncating the user's request or marking undelivered history as delivered.

Actual behavior / impact

The parent conversation could not progress through ordinary messages. Work had to move to a fresh conversation. The affected conversation was blocked completely.

Failure localization

The known window does not prevent this gate from reaching zero. handoffBudget reserves max(16000, ceil(window / 4)) in addition to current-message/attachment allowance:

window:                      475,000
used:                        356,824
reserve: ceil(475,000 / 4) = 118,750
remaining before user text =    -574
handoff budget after clamp =       0

There were 118,176 tokens of nominal window headroom, but no allowance for a handoff under this reserve policy. This does not prove that the full next provider request would fit.

The public turn-start path in ProviderTurnStartService.ts invokes deliverContextHandoffs with this budget and deferInline: compact. ContextHandoffDelivery.ts still throws ContextHandoffBudgetError when selected history/coverage exceeds the budget on an ordinary turn. Even a retrieval pointer cannot fit a zero budget. Repeating an ordinary message reaches the same pre-provider failure gate.

Proposed resolution and checks

1. Prefer the existing fix(server): a handoff too large for the context window no longer wedges the thread #19414 direction: defer oversized handoffs, allow the ordinary turn to proceed, and retry delivery later when capacity is available. Preserve pending content and delivery certainty; do not mark deferred history as delivered.
2. Include this known-window/quarter-window-reserve case in regression coverage, alongside the unknown-window case: budget clamps to zero; ordinary messages do not repeatedly fail solely because a handoff cannot fit; pending results survive and can later be delivered without duplication.
3. Treat automatic native compaction / compact-and-retry as a separate product-policy decision. fix(v2): compact full sessions before provider handoffs #15213 and fix(v2): compact full sessions before provider handoffs #13123 already cover that direction; this report does not establish maintainer approval for it.

No runtime patch or competing PR is submitted here. Could you assign this issue to @dajiaohuang if a distinct follow-up is useful and available? If #19414 fully covers it, please link/close this as related or duplicate rather than start a second implementation.

Related reports and proposals — quoted for comparison

• #16147 — original OpenCode unknown-window report:

  The provider thread's contextUsage was { "usedTokens": 581117 } with no maxTokens.

  My incident had a measured maxTokens of 475,000, so repairing OpenCode window discovery alone would not address this trigger.

• #19414 — existing deferral fix, currently OPEN/unmerged:

  An oversized handoff is persisted with an optional deferred: true flag, and the turn proceeds without it.

  This directly targets the shared failure gate. Its current head was e89c97f50f898cebbe90969a1eb69304c118331e when checked; I have not independently validated it with a live provider.

• #15213 — automatic compaction proposal, currently OPEN:

  Maintainer approval of the direction and scope is still pending.

• #13123 — earlier compaction PR, currently CLOSED:

  V2 now compacts that same session, then retries the unchanged request once.

  These describe a different recovery approach; their existence is not evidence that it is approved or deployed.

Workaround and verification limits

• Moving the work to a fresh conversation restored progress.
• The dedicated /compact command / Compact context action was not tested in this incident. A failed natural-language request is not evidence that the dedicated action is broken.
• No new live-provider reproduction, local regression test run, or validation of fix(server): a handoff too large for the context window no longer wedges the thread #19414 was performed for this report. The evidence is the observed incident, measured usage, and matching source path.
• Sanitized report only: no prompts, raw logs/database, credentials, host addresses, local project paths, or conversation identifiers are attached.