[Windows Desktop] Selected recent task stays blank while collaboration hydration starves app-server queue #36914

Activity

1. cutthreat

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 4, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   performance

   on Aug 4, 2026
3. github-actions commented on Aug 4, 2026

   

   github-actionsbot

   on Aug 4, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [Codex App][Remote SSH] Thread hydration blocks the app-server queue and causes an endless reconnect loop #36189

   Powered by Codex Action
4. jyongchul commented on Aug 25, 2026

   

   jyongchul

   on Aug 25, 2026

   More actions

   Additional reproduction: 26.818.8289.0 turns queue starvation into a false sign-in / fully black window

   I can reproduce the same scheduler starvation on a newer Microsoft Store build, with an additional authentication failure mode.

   Environment:

   • Windows 10 Pro 10.0.19045 x64
   • Codex Desktop 26.818.8289.0 (Get-AppxPackage status: Ok)
   • Packaged app server: codex-cli 0.149.0-alpha.4.3
   • Installed primary runtime: codex-cli 0.149.0-alpha.4.3 (versions match)

   Observed behavior:

   • The primary window became completely black except for the native title bar at 16:53 and remained identically black at 17:48.
   • All nine ChatGPT.exe processes and the packaged codex.exe app-server process remained alive; Windows reported the UI processes as responding.
   • There were no matching WER, Application Hang, Application Error, display-driver, or GPU reset events.
   • The app intermittently asked the user to sign in even though the local ChatGPT credential had successfully refreshed and remained valid.

   Sanitized timeline from the desktop log (KST):

   09:10:27 first app_server_client_request_queue_rejected
            inFlightRequestCount=4 queuedBackgroundRequestCount=128
            reason=queue-full source=collab_hydration method=thread/turns/list
   
   16:45    repeated Failed to retrieve authentication token, status=432
   16:46:55 response_orphaned for desktop-auth and account/read,
            followed by No promise for request ID
            one account/login/start response durationMs=1053069 queueWaitMs=57012
   16:47:08 auth.json last_refresh advanced successfully; credential was still valid
   
   17:48:32 app_server_client_request_queue_rejected
            inFlightRequestCount=6 reason=queue-expired
            configRequirements/read, mcpServerStatus/list, config/read, model/list
            renderer: App server request expired while queued
   

   Local history size may be an important amplifier: sessions contains 3,090 rollout JSONL files totaling about 157 GiB; 34 files modified in the last 24 hours alone total about 10.9 GiB, and the largest individual rollout is about 11.6 GiB. This looks consistent with background collaboration/history hydration filling the bounded queue and starving interactive/auth/config work. The authentication prompts appear secondary, not a real expired-login condition.

   Questions for maintainers:

   1. Can auth, visible-window config, and selected-thread reads preempt/cancel background collaboration hydration?
   2. Can stale pending auth requests be cancelled without orphaning the response and deleting the promise?
   3. Is moving inactive rollout JSONL files out of ~/.codex/sessions a supported temporary recovery, or is there another safe compaction/reindex operation?
   4. Can the app detect this queue state and restart/reconnect its app-server automatically instead of leaving a live but black window?

   I am testing a reversible workaround: preserve inactive session files outside the live sessions tree, then fully restart the process tree. I can report the result here. No raw logs, task text, account identifiers, credentials, tokens, request IDs, or local user paths are included.
5. jyongchul commented on Aug 25, 2026

   

   jyongchul

   on Aug 25, 2026

   Last edited by jyongchul

   More actions

   Workaround test result and correction

   I tested two changes together: a full Microsoft Store app/app-server restart, plus temporarily moving session files not modified in 24 hours outside the live ~/.codex/sessions tree.

   Initial result:

   • The primary window rendered again instead of remaining fully black.
   • New auth requests completed normally, with no new response_orphaned or Failed to retrieve authentication token events.
   • There were initially no new queue-rejection events.
   • One later thread/read still took 40.519 seconds with a 5.156-second queue wait and produced a non-auth No promise for request ID event, although the UI remained rendered.

   Important correction: moving rollout files is not a viable workaround. The sidebar/index retained those sessions, but selecting one produced:

   Failed to resume chat
   failed to resolve rollout path ... file does not exist
   

   Restoring that exact rollout file made the session load successfully. I then restored all remaining files to the live session tree (3,056 total files restored, zero collisions); none remain archived or deleted.

   This leaves a full process-tree restart as the only verified temporary recovery. Local history volume (about 3,090 rollouts / 157 GiB in this reproduction) is still a likely amplifier, but deleting or moving rollouts breaks indexed history and should not be recommended. A supported compaction/indexing mechanism plus interactive/auth request priority is needed.
6. twentyOne2x commented on Aug 27, 2026

   

   twentyOne2x

   on Aug 27, 2026

   More actions

   macOS 26.820.60940: startup hydration saturates the shared six-slot queue across repeated relaunches

   Adding a current macOS reproduction of the same scheduler/backpressure failure. This report is sanitized: no task text, thread/request IDs, account data, project names, private paths, or raw logs are included.

   Environment:

   • ChatGPT/Codex Desktop 26.820.60940 (build 7119)
   • bundled app-server codex-cli 0.150.0-alpha.8
   • macOS 26.3 (25D125), Apple Silicon

   Impact and timeline:

   • App-level queue starvation was present before the user-recalled approximately 10:20 onset; two focused Composer submissions had already timed out.
   • From termination of the original main-app process at 10:19:32 until shutdown began at 12:23:06 was 2h03m34s.
   • Three relaunches at approximately 10:43, 11:32, and 12:04 all degraded. Restarting the app did not restore reliable interaction. User-observed recovery followed the reboot, but the primary-runtime install described below had completed shortly beforehand, so the recovery cannot be attributed solely to reboot.

   Queue/hydration evidence:

   • Each failed launch attempted to hydrate roughly 80 task IDs.
   • On the first relaunch, the first queue rejection appeared about 81 seconds after process start, with all six request slots occupied and 91 background requests queued.
   • The final relaunch recorded 272 app_server_client_request_queue_rejected events and repeatedly reached inFlightRequestCount=6. queuedInteractiveRequestCount reached 64, after which additional requests were logged as queue-full.
   • The same run recorded 243 hydration-related log events; config, model, plugin, thread-list/read/turns, and Composer operations expired or were rejected behind the shared queue.
   • A post-reboot, read-only local-state inventory contained approximately 23,000 thread records, about 8,850 unarchived. That scale is an amplifier, not proof that any individual thread was malformed or that the counts were identical during the outage.

   The macOS hang report at 11:49 captured a real Electron/ChatGPT hang. The main UI thread had not run for about 238 seconds at sample time. That is one lower-bound point sample, not the overall outage duration.

   Resource negative controls:

   • 128 GB physical RAM; no OOM/ENOMEM evidence
   • ChatGPT footprint approximately 293 MB in the hang report
   • approximately 117 GB free disk, versus a roughly 3 GB macOS low-space threshold
   • no ENOSPC, disk-full, GPU-crash, or renderer-crash evidence; thermal pressure was level 1 (low), with no thermal-shutdown evidence

   The third relaunch also installed a missing primary runtime. The configured runtime bundle was approximately 353 MB, and the install operation took about 17 minutes. Queue failures predated that install and continued after it completed, so it appears to be an amplifier rather than the initiating cause.

   macOS also recorded a disk-write diagnostic during the incident, but that report does not prove storage saturation or causation. The strongest direct application evidence is still the bounded app-server queue being filled by background hydration while interactive operations expired.

   Suggested acceptance criteria remain aligned with this issue:

   1. Selected-task and Composer operations must preempt background hydration.
   2. Startup hydration should be bounded, cancellable, generation-aware, and coalesced.
   3. A slow thread must not occupy a global scheduler slot indefinitely.
   4. Queue saturation should trigger automatic recovery/circuit breaking rather than requiring an app or OS restart.
   5. Desktop should provide a safe-start path that loads a bounded recent tail instead of restoring all retained work eagerly.

   Related current reports: #23644 for macOS Composer/app-server timeouts, #35083 for retained in-app Browser renderer lifecycle, #21007 for macOS UI lag and disk-write diagnostics under low resource pressure, and #38385 for the same six-slot scheduler failure affecting every Desktop window.
7. jahidrfc commented on Aug 31, 2026

   

   jahidrfc

   on Aug 31, 2026

   More actions

   Additional sanitized evidence from a separate Windows run:

   • CodexBeta 26.727.4816.0
   • The window remained focused and visible.
   • One run issued 485 distinct interactive thread/archive requests: 68 succeeded and 417 were rejected as queue-full.
   • The 417 failures occurred within 7.343 seconds; pending work rose from 71 to 487.
   • Failed-request duration: p50 7,181 ms, p95 7,672 ms, max 7,710 ms.
   • The same run emitted 591 unknown-conversation lifecycle events.
   • A pre-restart process snapshot reported node_repl=102, 1,229 OS threads, 16,762 handles, and approximately 4.9 GiB app-server private memory. A full app restart dropped those baselines sharply.

   The archive storm followed substantial thread/collaboration-history activity and may be related to the hydration/lifecycle behavior described here. The available telemetry does not identify the archive targets, and it cannot establish whether the burst was automatic or initiated by a bulk action, so I am not claiming confirmed subagent targets or a confirmed trigger.

   This adds evidence of a short, self-amplifying interactive request burst that can fill the shared queue even while total CPU and RAM remain below saturation. Coalescing lifecycle work, bounding archive dispatch, reserving capacity for visible-task operations, and invalidating obsolete hydration generations may be useful areas to inspect.

   No raw logs, task/request IDs, filesystem paths, prompts, task contents, account data, or screenshots are included.