[Windows Desktop 26.915.4065.0] Recurrent unresponsive task; control requests expire with 5–6 in flight, manual restart required

Problem and impact

Codex Desktop on Windows repeatedly becomes unresponsive during a long-running development task. New messages are not acted on while the task still appears active. I have had to restart the app manually to resume work, and the problem recurs. This is disrupting delivery and requires repeated recovery from saved checkpoints.

This is a recurrence report on Windows package OpenAI.Codex 26.915.4065.0, verified with Get-AppxPackage on September 18, 2026. The package version is not being presented as the About-dialog or bundled backend version.

Observed evidence from the September 18 incident

All times are UTC. Only selected diagnostic fields are included.

• Retained local validation receipts show the owned test, compiler and lint processes had all finished successfully by 20:40:14, with exit code 0 and zero remaining owned children. The app was not simply waiting for that validation to finish during the later incident.
• The desktop log contains repeated control-request queue expirations before the user-triggered restart.
• At 21:08:52.668, an expanded preceding log range records six in-flight requests at queue-expiration events.
• The following selected later events record five in-flight requests:

2026-09-18T21:09:23.701Z
  method=config/read inFlightRequestCount=5
  queueWaitMs=30008 queue-expiration

2026-09-18T21:13:18.653Z
  method=app/installed inFlightRequestCount=5
  queueWaitMs=30000 queue-expiration

2026-09-18T21:13:48.655Z
  method=thread/list inFlightRequestCount=5
  queueWaitMs=60002 queue-expiration

2026-09-18T21:14:57.224Z
  method=config/read inFlightRequestCount=5
  queueWaitMs=30004 queue-expiration

These excerpts preserve selected fields, not complete raw log lines. Repeated events are not counted as separate incidents or unique requests.

• Process creation-time checks show a new desktop process at 21:21:12.539 UTC and a new backend at 21:21:18.527 UTC; the earlier processes are absent. The user confirms manually restarting after the hang. This is not evidence of an independently proven process crash.
• Work and tool responses resumed after the restart. That demonstrates recovery for this occurrence, not a permanent fix.

Reproduction status and limits

The visible sequence is ordinary continued use, stalled responses to new input, then manual restart. The exact initiating operation is not yet isolated. Multiple tools and delegated agents are used, but their presence alone is not proof of the cause.

The expiring method names are requests blocked by the problem; they do not identify the original requests occupying the slots. No synchronized process dump, blocking-pool trace, or complete transport trace was captured. The current evidence does not establish RAM exhaustion, a particular plugin, network failure, or a specific backend handler as the cause.

Related reports and requested resolution

This resembles #43525 and #38385. #43122 and #42740 describe potentially related MCP session-retention and Windows blocking-pool mechanisms, but those mechanisms are not claimed as proven for this installation.

Please triage this recurrence on the September 15 package and identify any supported fixed build or mitigation. In particular:

1. Capture the method, age and wait state of already-dispatched requests when control operations begin expiring.
2. Keep steering, cancellation and recovery responsive when metadata/plugin/history requests stop completing.
3. Surface an explicit stalled/error state instead of leaving a task apparently active without useful progress.
4. Recover safely without requiring repeated full app restarts or replaying operations with unknown outcomes.
5. Clarify whether the related fixes cover live retained sessions as well as teardown.

Please consolidate with the existing issue if this is the same defect. No raw logs, conversation contents, project names, local user paths, credentials or patient/financial records are attached.

Start by reproducing the Windows desktop hang while collecting the desktop log, request wait states, process information, and complete transport or blocking-pool traces; compare the behavior with related issues #43525, #38385, #43122, and #42740. Done means identifying the initiating mechanism or consolidating with the matching defect, then documenting a supported fixed build or mitigation that preserves responsive control and recovery without repeated restarts.