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

Open 💬 4 comments Opened Aug 4, 2026 by cutthreat

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.727.6591.0

What subscription do you have?

Unknown (not exposed in the reportable Desktop diagnostics)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Selecting a recently active task can leave the content pane blank/loading for a long time even though the task content is present. The selected task competes with background collaboration/history hydration in the same bounded app-server request queue. Interactive reads can remain queued until the 60-second deadline expires.

A bounded local verifier aggregated scheduler fields only; no task text, credentials, profile data, or raw logs are attached.

Hydration queue expiries in 24 hours: 42
Hydration queue expiries in the latest 120 minutes: 28
Maximum queue wait: 60017 ms
Maximum shared in-flight requests: 6
Maximum queued critical requests: 16
Maximum queued interactive requests: 63
Sources: collab_hydration, thread_hydration, recent_threads, tail_history, thread_list
Methods: thread/list, thread/read

Sanitized event shape:

app_server_client_request_queue_rejected method=thread/list
priority=background queueWaitMs=60010 reason=queue-expired
source=collab_hydration

Installed app.asar SHA256: 670A43EA0DCF6D2583F77272354CF076D1A2D5D9949873C4923C9534D86EA298

What steps can reproduce the bug?

Have several recent tasks with collaboration/sub-agent activity.
Restart Codex Desktop.
Select a recently active task while background hydration is running.
Observe a blank/loading content pane. Content may appear only after a long delay.

The issue reproduces without task-content loss. Packaged-source readback shows a shared global limit of six requests; historical collaboration hydration can request a large descendant list and issue multiple thread/read calls while the selected task is waiting.

What is the expected behavior?

Selecting a task should preempt background history hydration. The latest visible tail should render first. Background descendant hydration should be cancellable and coalesced per ancestor/generation, and a selected-task read should never wait behind a previous generation until the 60-second queue deadline.

Additional information

Suggested acceptance criteria:

With at least 50 collaboration descendants queued, the selected task renders first content within 2 seconds.
Interactive thread/read queue wait stays below 500 ms at p95.
Changing selection cancels or invalidates queued background work from the previous selection generation.
Repeated background hydration requests for the same ancestor are coalesced.
No selected-task request expires with reason=queue-expired.
Restarting Desktop with multiple recent collaboration-heavy tasks does not produce a blank selected-task pane.

Related: #25779 and #16817.

Privacy: no screenshot is attached because the reproduction contains private task names. No raw logs, task IDs, task contents, credentials, cookies, tokens, OAuth material, browser profile data, or history are included.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 23 days ago

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

#36189

Powered by Codex Action

jyongchul · 3 days ago

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:

Can auth, visible-window config, and selected-thread reads preempt/cancel background collaboration hydration?
Can stale pending auth requests be cancelled without orphaning the response and deleting the promise?
Is moving inactive rollout JSONL files out of ~/.codex/sessions a supported temporary recovery, or is there another safe compaction/reindex operation?
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.

jyongchul · 3 days ago

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.

twentyOne2x · 14 hours ago

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:

Selected-task and Composer operations must preempt background hydration.
Startup hydration should be bounded, cancellable, generation-aware, and coalesced.
A slow thread must not occupy a global scheduler slot indefinitely.
Queue saturation should trigger automatic recovery/circuit breaking rather than requiring an app or OS restart.
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.