Repository navigation
[Windows Desktop] 26.903.8094.0 app-server queue blocks plugins and Remote Control; recent history omitted after restart #44401
Description
Codex Desktop on Windows repeatedly becomes partially unusable. Messages sometimes fail to send, @ stays on "Loading plugins...", plugin setup says "Failed to load plugin connection", slash commands fail, and Remote Control cannot load devices or save availability. The user reports that symptoms recur after restarts.
Current installed package: OpenAI.Codex 26.903.8094.0. Incident observed September 10, 2026, approximately 02:58–03:30 UTC.
Local AppServerConnection logs show 5–6 in-flight requests and 64 interactive requests queued. plugin/list expires while queued after 30 seconds. remoteControl/client/list and remoteControl/disable are rejected with code -32001, "App server request queue is full". config/read, model/list and history requests also expire. Some turn/steer requests still receive immediate replies.
Please investigate requests retaining scheduler slots, MCP extension-host lifecycle and possible Windows stdio blocking-pool exhaustion. Related reports: #43122 and #42740. Our current renderer has staleTime:Infinity without an explicit gcTime on mcp-extension-host-thread, but we have not proved the live eviction trigger or identified which dispatched requests are retaining scheduler slots.
Remote behavior differs between accounts. The same underlying cause on other devices is unverified. Please provide a durable fix and a safe recovery that preserves active work, plugins and credentials.
Additional incident after restart around 03:46 UTC: the conversation UI restored older scheduled-task turns instead of the recent diagnostic messages. Native process creation times confirm the app was replaced. The local JSONL contains actual assistant message records from 03:40:11 and 03:43:55 before restart and continues to append after restart. A task-history read also returned older in-progress turns. Recent records were persisted; why they are omitted from the displayed history is unresolved. This may be a separate history-loading defect. No session database, conversation file, credential or plugin cache was changed during this investigation.
Activity
github-actions commentedon Sep 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
wherewolf87 commentedon Sep 10, 2026
Additional measured evidence after another restart (2026-09-10 UTC):
The user observes that running more than one user-visible chat is associated with the app becoming unresponsive. I have not performed a controlled multi-chat reproduction.
At 04:29:38 UTC, a native Windows Toolhelp snapshot with creation-time-ordered parent chains attributed 271 Node/Python/shell workers to the current Codex backend. Their summed private bytes were 15,824,072,704 (about 14.7 GiB). The backend itself had 557 OS threads. A separate Claude process tree had 53 comparable workers and 3,604,955,136 private bytes; these were excluded from the Codex figure. OS thread count does not establish how many threads belong to the blocking pool.
The current desktop instance began around 04:10 UTC. Its bounded main-log read through 04:28 records 10,227 mcp_server_startup_status_updated events across seven internal task IDs, each involving 106 distinct server names. These are repeated state events, not a claim of 742 simultaneous local processes. The same log includes queued model/list, plugin/list, config/read and app/installed rejections. The prior instance again reached six in-flight requests before the user's next restart.
Our existing local shared broker was stopped at the time of the 04:29 snapshot. Its source repairs were installed at 04:25, but controlled service startup was not invoked until 04:31. Therefore the measured 271 Codex-descendant workers do not come from that new broker startup.
This adds correlation between concurrent/internal sessions, repeated MCP startup and queue failures. It does not identify the exact request holding each scheduler slot or prove a single root cause. Issue #43525 appears closely related to the shared control queue; #42740 and #43122 remain relevant hypotheses. No raw logs, conversation content, credentials, device identifiers or browser tabs are attached.
wherewolf87 commentedon Sep 10, 2026
Additional recovery evidence after another user-reported full computer restart (2026-09-10 UTC):
No raw logs, credentials, browser tabs, account identities or business documents are attached. Please advise on a supported Desktop release or remedy for the recurring request-queue stalls and retained local MCP stacks.
wherewolf87 commentedon Sep 10, 2026
Another owner-reported full-computer restart after three visible tasks became unresponsive (2026-09-10 UTC). Screenshot again shows "App server request expired while queued" and messages could not be sent.
A complete bounded read of the 9,449,855-byte pre-restart main log found the last response_routed at 06:47:45.299 UTC. Queue rejections continued through 07:14:44.410, including turn/steer. The final entries report inFlightRequestCount=6, queuedInteractiveRequestCount=19 and queueWaitMs approximately 30000. model/list, config/read and configRequirements/read also expired. No bridge_forwarded_to_transport debug events were present, so the six held requests cannot be identified from this log.
Windows event queries covering 05:00–07:19 UTC found no matching System resource-exhaustion event2004 or Application error/hang1000/1002. This is not proof of no memory pressure. A separate older incident on September8 did record 99.906% commit exhaustion, followed by a Codex crash three seconds later; we are keeping that distinct from this queue incident.
After restart, a07:22 native memory sample showed63.71GiB usable physical RAM,43.99GiB physical available, and73.71GiB available under a95.71GiB commit limit. A07:20 birth-ordered process snapshot attributed78 Node/Python/shell workers and3,852,599,296 private bytes to the new backend. This is post-restart data, not a pre-crash estimate.
The existing local broker had independently passed20/20 configured server health/tool checks at06:46 before the stall; broker health clearly does not establish Desktop queue health. No raw logs, credentials, account identities, business documents or browser content are attached. Please advise on a supported fix or additional bounded diagnostic for the retained six in-flight requests.
AuraquanTech commentedon Sep 10, 2026
Additional independent Windows observation on the same Desktop package,
26.903.8094.0.I followed one ChatGPT.exe-owned
codex.exe app-serverusing PID + creation-time identity and only its descendants. This changes how I would classify the process growth: the worker forest was large and temporarily retained, but it was not permanently leaked in this observation.At 23:37:24 local time (UTC-05), the unchanged app-server had 720 descendants, including 718 Node/Python/shell workers. Direct-child creation times formed several compositionally similar MCP/runtime clusters.
A read-only sampler then followed that same app-server without killing or reconfiguring anything. Samples 1–6 remained at 720 descendants / 142 direct children / 718 workers. Between samples 6 and 7, the tree spontaneously dropped to 528 descendants / 108 direct children / 526 workers, with no new process identities observed during the sampling window. It remained at 528 through sample 12.
Hours later, the same app-server PID was still alive but had only two descendants (the console host and code-mode host); the 718-worker forest had exited.
So this run supports temporary accumulation with delayed/staged cleanup, not monotonic or permanent process leakage. It does not establish the cleanup trigger, whether the accumulation contributed to the request-queue failures reported here, or the specific five-minute
mcp_extension_hostmechanism in #43122.All measurements were read-only. No process was stopped or reconfigured, and no prompts, credentials, raw configuration, or private logs are included.
AuraquanTech commentedon Sep 10, 2026
Follow-up on the same unchanged ChatGPT.exe-owned
codex.exe app-serverPID 56172:At 03:06:30 local time (UTC-05), a read-only snapshot showed only two descendants:
conhost.exeandcodex-code-mode-host.exe. At 03:08:56—approximately 2m26s later—the same app-server PID had re-expanded to 638 descendants, including 129 direct children and 634 Node/Python/shell workers, with approximately 18.5 GiB aggregate private bytes.A 31-sample identity-based observation from 03:08:56 through 03:30:33 found the same 638 descendant identities throughout samples 2–31: Births=0, Exits=0, Survivors=638. Aggregate private bytes ranged approximately 18.5–19.3 GiB. No process was killed or reconfigured.
This adds evidence of repeated large worker-forest re-expansion after near-complete delayed cleanup under one continuously alive app-server, followed by stable retention for approximately 21.5 minutes. It does not contradict the prior observation that the earlier 718-worker forest eventually exited, and it still does not establish a permanent leak.
The trigger for cleanup and re-expansion remains unknown. This observation does not establish that the forest caused the request-queue failures, identify retained scheduler requests, or attribute the recurrence to the controlled five-minute
mcp_extension_hostmechanism described in #43122.All measurements were read-only and identity tracking used PID + creation time.
wherewolf87 commentedon Sep 10, 2026
Additional reproducible in-app browser interaction stall, Windows, 2026-09-10 UTC. Native Codex backend reports 0.153.4.
In a fictional localhost application, clicking a link that invokes window.confirm caused Input.dispatchMouseEvent to time out after approximately 14 seconds. Dialog lookup returned undefined. Attempting Page.handleJavaScriptDialog failed because Emulation.setFocusEmulationEnabled timed out first.
While that tab remained open, a second in-app browser tab loaded and accepted form filling, but its Send clicks produced no HTTP events. Closing only the stalled fictional test tab immediately restored clicks in the second tab: the same form then produced POST /api/feedback HTTP 201. No Desktop restart, process kill, or configuration change was performed. The saved fictional entry also survived a page reload.
A bounded read of the active diagnostic log independently confirms Input.dispatchMouseEvent timing out at 11:24:35.503 UTC and repeated Emulation.setFocusEmulationEnabled timeouts at 11:24:36.550, 11:24:56.558, 11:25:16.576 and 11:25:36.591. Windows reported 26.76 GiB physical RAM free of 63.71 GiB at 11:26:08 UTC. This sample does not support contemporaneous physical-RAM exhaustion.
Hypothesis, not an established internal cause: a pending native confirmation blocks a host focus-emulation prerequisite, preventing the dialog-dismissal command from reaching the browser. Please investigate whether native dialog handling can bypass that prerequisite and remain operable while a modal is pending.
We replaced this application's native confirmation with an in-page dialog and are verifying the rebuilt interaction. This is an application-side mitigation, not proof that the host defect is fixed or that it explains all earlier queue, plugin, or multi-session failures. No raw diagnostic logs, credentials, private application data, or screenshots are attached.
wherewolf87 commentedon Sep 10, 2026
Controlled worker-isolation result, Windows, 2026-09-10 17:12 UTC, native Codex 0.153.4:
A single
codex exectask used the existing home/authentication, ephemeral mode, read-only sandbox, and explicit per-run disables for all 85 configured MCP registrations. Apps, plugins, remote_plugin and skill_mcp_dependency_install were also disabled for this invocation. No global configuration or credentials were changed.Before the model request, native inventory returned exactly 85 matching server names, all disabled, with no additional entries. A separate actual sandbox probe read its fixture successfully and denied file creation. Both commands exited cleanly.
The model task returned the expected small JSON response in 10.59 seconds and exited 0. A retained Windows Job Object reported zero active processes afterward, without forced termination. JSONL contained no MCP startup events and no tool calls. The sampled owned forest contained six unique processes (Codex, PowerShell and console hosts), with no sampled Node/Python/provider worker. Sampling was every 500 ms, so this is not an assertion that every very short-lived process was captured.
There was a separate nonfatal
item.type=errorevent: “Exceeded skills context budget. All skill descriptions were removed and 1077 additional skills were not included in the model-visible skills list.” The turn still completed, using 26,575 input tokens for the minimal response. Plugin exclusion did not eliminate personal-skill catalog loading in this run.This supports a bounded CLI workaround for avoiding inherited MCP startup during local-only work. It does not establish that native Desktop subagents use these exclusions, cure the Desktop request queue stalls, or prove long-term concurrent-session stability. Please consider supported per-worker MCP/skill scoping so local code-review agents can retain necessary instructions without repeatedly loading the entire integration and skill catalog.
No raw configuration, authentication material, conversation data, or diagnostic logs are attached.
wherewolf87 commentedon Sep 11, 2026
Source-level follow-up on completed subagent runtime retention (reviewed rust-v0.153.4 and rust-v0.154.0):
The current exposed V2 collaboration surface provides interrupt_agent but no close_agent operation. Interrupt stops a turn while retaining the loaded session. The legacy V1 close_agent path calls shutdown for the child and descendants.
The supported app-server thread/unsubscribe operation removes only the calling connection's subscription. A separate diagnostic client cannot use it to remove the Desktop connection's subscription. Last-subscriber unloading also uses a 30-minute inactivity interval rather than immediate release.
V2 has capacity-triggered eviction of eligible idle subagents. Completion alone is therefore not an immediate teardown contract. This is source evidence, not a demonstrated cause of the six-request queue stall, proof of a permanent leak, or measured Windows descendant cleanup.
Relevant source:
Could a supported V2 operation release a completed subagent's MCP runtime promptly without terminating unrelated user tasks, or could completed local-review workers opt out of retaining integrations? We are keeping the Desktop-managed backend unchanged and using the previously described bounded, MCP-disabled CLI workaround for local-only review. No lifecycle RPCs, process kills, private logs, configuration or credentials are included in this update.
HomeHeartTherapy commentedon Oct 1, 2026
Additional Windows Desktop incident on September 30, 2026: chat resume is blocked by the same queue-full error.
At approximately 21:08 UTC, the app displayed this exact error:
The selected chat showed a central loading spinner and a disabled message composer. This has happened before, and it prevents me from continuing work in the desktop app. I need a supported way to recover without exiting or restarting the entire app.
Observed sequence
This is an observed incident, not a deterministic minimal reproduction. The action that originally filled the queue is unknown.
Environment and evidence limits
helper_sandbox_lock_failedandSetNamedSecurityInfoW sandbox dir failed: 5. Whether this separate sandbox setup failure is related to queue saturation is unknown.Expected behavior and request
Resuming a chat should complete and restore input. If the app-server queue is saturated, the app should surface a bounded, actionable recovery path that preserves active work and chat history without requiring an application exit.
Please investigate whether this is the same request-lifecycle problem tracked here, advise which targeted, privacy-safe diagnostics would identify the request or component holding up the queue, and provide a supported no-restart recovery or fixed build.
I am adding this incident here per the repository's guidance to contribute new information to an existing report. Similar visible queue-full symptoms are reported in #48917, but I have not established the attachment-request mechanism described there on my machine.