[Windows][Desktop] Fork can start near context limit, then stall during notes/new-context handoff

Summary

A fork of a long-running task looked like a new work surface but began with 70.7%
of its effective model context already occupied. It required a context replacement
less than six minutes after creation and six replacements over approximately seven
hours.

During the sixth transition, several direct user follow-ups received no final
answer. Three attempts ended after 52–74 seconds. The successful turn took 114.8
seconds and durably performed checkpoint append, new_context, context replacement
and checkpoint read before producing its final answer.

After replacement, request context fell from about 200K to about 40K tokens. The
task then made a concrete continuity error by proposing an already-approved method
as a new solution and subsequently acknowledging that it had failed to apply the
existing method.

Environment

• Windows 11 25H2, build 26200.9168
• Codex Desktop 26.901.6511.0
• gpt-6-astra, xhigh, default service tier
• Experimental notes/history context management enabled
• Local task; six-predecessor fork lineage

Reproduction observed in ordinary work

1. Continue a substantial local task through a series of forks.
2. Create another fork for a new workstream.
3. Work normally until the experimental context workflow reports near exhaustion.
4. Send a follow-up while checkpoint/new-context housekeeping is still required.

This was a natural occurrence, not a deliberate stress test.

Expected

• Show inherited context pressure when a fork is created.
• Compact or transition proactively before accepting a prompt that cannot complete
  in the current context.
• Queue or safely merge user follow-ups during mandatory context housekeeping.
• Preserve the approved workflow after transition, or recover the relevant history
  before answering.
• Expose that the delay is context management rather than ordinary model reasoning.

Actual

• Effective context window: 258,400 tokens
• First call in the new fork: 182,789 input tokens (70.7%)
• Same first turn before replacement: 216,741 input tokens (83.9%)
• First replacement: 5m 51s after fork creation
• Replacements during the child task: six
• Final pre-failure warning: 3,171 tokens remaining
• Three interrupted attempts: 74.246s, 56.274s and 52.395s
• Successful handoff/answer turn: 114.798s
• First post-transition answer: one checkpoint read, no history search
• Following request context: approximately 39,800–41,700 input tokens

The child rollout was 22.85 MiB at a later bounded capture. That is the child's
own post-fork growth, not the inherited-history size; the initial input-token count
is the relevant context-pressure measurement.

Backend evidence

During the 15:51–15:59 CDT incident window, 123 Desktop log lines were tagged to
the affected task:

• zero error-level lines
• zero warning-level lines
• zero non-null RPC error codes
• seven turn/start calls completed in 26–99ms
• maximum recorded queue wait: 0ms

Reasoning and later completion events continued. This does not look like a server
admission failure or a silent model downgrade.

Why this appears to be a product bug

Fork inheritance itself may be intentional, but the product provides no usable
warning that a visually new fork can begin mostly full. Mandatory context
housekeeping then occupies user-visible turns and can be repeatedly interrupted by
follow-ups that the product accepts. The first answer after replacement may rely
only on an agent-authored checkpoint even when the task's detailed prior method is
material to correctness.

Current OpenAI model guidance says Astra supports compaction. The compaction
guidance also recommends monitoring context, planning ahead to avoid limits,
compacting after milestones and keeping prompts functionally identical when
resuming:
https://developers.openai.com/api/docs/guides/latest-model
https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.2

I am not claiming compaction alone caused the underlying content defect; that
defect existed beforehand. The report concerns undisclosed inherited pressure,
the user-visible hard-stop handoff, and weakened task continuity afterward.

Related issues

• #25467 covers context growth after a conversation fork.
• #32506 covers model-visible context missing from a Desktop fork.
• #33310 proposes an atomic context-handoff primitive.
• #26826 covers slow automatic compaction after pause and resume.

None covers this combined Desktop sequence of inherited fork pressure,
interruptible notes/new-context housekeeping and weakened continuity afterward.

Privacy

Task titles/IDs, usernames, paths, prompts, transcript text, checkpoint contents,
raw logs and project subject matter are intentionally omitted. No attachment or
session share is included.

Start with the documented fork sequence and the 15:51–15:59 CDT Desktop log evidence, then compare the behavior with related issues #25467, #32506, #33310 and #26826. Done means inherited context pressure is visible, mandatory handoff work is safely handled around follow-ups, and continuity is preserved after replacement without treating the issue as a server admission failure.