Repository navigation
[Windows Desktop 26.915.4065.0] Recurrent unresponsive task; control requests expire with 5–6 in flight, manual restart required #46479
Description
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:
- Capture the method, age and wait state of already-dispatched requests when control operations begin expiring.
- Keep steering, cancellation and recovery responsive when metadata/plugin/history requests stop completing.
- Surface an explicit stalled/error state instead of leaving a task apparently active without useful progress.
- Recover safely without requiring repeated full app restarts or replaying operations with unknown outcomes.
- 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.
Activity
github-actions commentedon Sep 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
wherewolf87 commentedon Sep 18, 2026
Follow-up: installed-version source inspection and a correlated timeout/late reply
The running backend reports codex-cli 0.155.0-alpha.9.2 via its supported version command; Windows package remains 26.915.4065.0.
Read-only inspection of the installed desktop bundle found:
plugin/listdoes not also coverplugin/installed.Inspected entry:
.vite/build/src-C3YaUE83.jsSHA-256:
14C8C23E8B8DFA874D3FB5A50D54FB28ECCF55FB83232C3AB29CB7C0EF0A0472A same-request correlation in the retained log confirms separation between caller timeout and eventual reply:
The reply arrived 45.347 seconds after the timeout. A later
plugin/installedrequest timed out at 21:08:52.665 UTC and has no routed reply in the inspected range ending 21:19:02 UTC.This identifies a mechanism that can preserve occupied host slots after the UI has timed out. It does not identify all outstanding requests, prove delivery of abandonment for that particular logged request, or establish why the backend delayed its replies. The event label
mcp_request_timeoutis not proof that an external MCP server caused the failure.No installed code was patched and no capacity limit was changed. Please investigate bounded recovery for sent requests while preserving unknown-outcome safety.
wherewolf87 commentedon Sep 19, 2026
Recurrence: message submission itself now times out while queued
The same user has reported another interruption and supplied a screenshot showing the exact toast:
The task remained visually active, with its elapsed-work label at 1h 27m 8s. That label is not a measurement of the length of this individual timeout. The user reports that these hangs occur every day, repeatedly require restarting the app, and are preventing normal productive work.
This is a new recurrence report, not a new diagnosis. The screenshot alone does not establish memory pressure or identify the backend operation occupying the queue. The Windows package/backend versions and the earlier correlated queue evidence are documented above; this screenshot is not fresh version verification.
Please escalate this for engineering triage and identify an officially shipped fix or supported mitigation. We especially need message submission, steering and cancellation to remain responsive when other app-server requests stall, with safe recovery for operations whose outcomes are unknown.
The original screenshot contains private workspace information, so only its exact error text and non-sensitive UI timing are included here. Raw conversations, credentials and business records are not attached.
wherewolf87 commentedon Sep 19, 2026
Additional user-reported reproduction: the same hanging behavior has also occurred on the owner's other computer. Matching versions and logs from that second computer have not yet been collected, so this is cross-device user evidence, not proof of a single identical root cause. Please investigate the shared application/account/configuration paths rather than attributing the issue solely to one machine.
The earlier six-slot evidence concerns internal control requests, not six user tasks or a memory limit. The open questions remain: which dispatched requests occupy those slots, why they stop completing, and how message submission/steering/cancellation can recover safely. Increasing the slot count alone would not establish a fix.
A new private Help Center escalation has now been confirmed as 'Escalated to a support specialist', referencing prior case 14600406 and this public report. No private conversation or screenshot has been posted here.
wherewolf87 commentedon Sep 19, 2026
Further recurrence on September 19: hours stuck on Thinking, repeated manual restarts
The problem is still disrupting work. The user reports that Codex remained frozen on Thinking for hours with no visible progress, and that they again had to restart the app. Multiple earlier messages in the same ongoing task report the same stall/restart/resume cycle. Exact per-incident start/end times were not instrumented, so the duration is user-reported, not a measured backend execution time.
Environment independently rechecked for this report:
Expected: the task makes observable progress, or reports a bounded timeout/error and permits steering, cancellation and safe recovery. A Thinking indicator should not conceal an indefinite stall.
Actual reported sequence: ongoing work, prolonged Thinking/no visible progress, manual app restart, request to resume saved work, recurrence. Saved project files and checkpoints remain available after restart; that does not establish that all in-memory work or pending operations survived.
Impact: hours of lost productive time, repeated manual intervention, delayed delivery, and uncertainty about which operations finished. Restarting has only been temporary recovery. This makes long-running unattended work unreliable.
Please escalate this continuing recurrence to Codex Desktop/app-server engineering, correlate it with the queue-timeout evidence already in this issue, and provide an actionable fixed-build status or supported mitigation. Please investigate stalled-request detection and recovery that preserves task state and avoids replaying operations with uncertain outcomes.
This update does not claim a fresh queue trace, process-crash dump, memory-exhaustion diagnosis, plugin attribution or a proven root cause. No private source, raw session transcripts, credentials, screenshots containing private work, or personal local paths are attached.
wherewolf87 commentedon Sep 19, 2026
Further owner-reported context: this same freezing behavior occurs continuously on another laptop running the latest Codex version, with 256 GB RAM, 24 GB VRAM and an NVIDIA 5090 GPU. These specifications and the second laptop's exact software version have not been independently verified in this report. The cross-device recurrence makes a simple hardware-capacity explanation less convincing, without proving a specific cause.
The owner also asks engineering to investigate whether simultaneous subagent activity contributes. This is an untested hypothesis, not a diagnosis.
The owner reports paid usage being consumed while the app remains stuck and no useful work is produced, blocked progress across projects, and missed deadlines. We have not independently quantified consumption attributable to the stalled intervals. Please investigate those sessions, provide a concrete fix or supported mitigation, and review the request for at least a usage reset or equivalent credit for the disruption. The billing/remedy request is also being added privately to the existing OpenAI support case.
wherewolf87 commentedon Sep 21, 2026
Root cause found and measured on my machine (Sep 20-21 2026): two stacked defects plus a design problem.
Same package as above (OpenAI.Codex_26.915.4065.0, backend 0.155.0), Windows 11 Pro 26200, 24 cores, 256 GB RAM (205 GB free during the freezes). All investigation was read-only.
1. The app-server wedges at about 256 live stdio MCP children (this is #42740)
Wait:UserRequestinside the desktopcodex.exe app-server= 2 x (piped child processes) + about 4 at every sample: 36 -> 76, 49 -> 102, 63 -> 130, 71 -> 146, 103 -> 209, 257 -> 515. The count clamps at about 512 and the process goes to 0% CPU for good./backend-api/codex/modelswith HTTP 200, while the frozen one loggedfailed to refresh available models: timeout waiting for child process to exitevery 275 s. Network, account, rate limits, RAM, NVMe, SQLite locking and Defender all measured healthy. (That log message is a mislabeled generic 5 s timeout; no child process is involved.)2. Why the ceiling is reached so fast: every thread and every subagent spawns its own full stdio MCP set and never gives it back
-c, cua_repl, node_repl, codex-security, openai-developers).max_concurrent_threads_per_session, and parked subagents keep all their MCP children. 0 thread shutdowns logged in two frozen runs; all 540thread_spawn_edgesrows are still "open".3. The desktop request scheduler turns the wedge into a lockout of every chat
var qW=6,JW=5,...): 6 requests in flight, 5 non-critical, not read from any setting. A dispatched request keeps its slot until the app-server answers; a renderer abandon frees the slot only for unsent requests, plugin/list and thread/resume.Workaround I applied
enabled = falseon resident stdio servers with no use (for plugin-supplied ones a per-server overlay[plugins."<plugin>@<marketplace>".mcp_servers."<server>"], for every marketplace copy), taking 13 resident per thread down to 3, andmax_concurrent_threads_per_session100 -> 16 so finished subagents actually get evicted. Budget rule: open chats x threads per chat x resident stdio servers well under 250.Requests
max_blocking_threadsinbuild_runtime().The full write-up was also sent to support@openai.com on Sep 21.