Windows Desktop UI lags during 100-thread attachment request bursts and app-server queue saturation #48917

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

   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 Sep 28, 2026
2. myloveislr-prog

   changed the title [-]Windows Desktop UI lags as thread-list refresh fans out 100 attachment requests and fills app-server queue[/-] [+]Windows Desktop UI lags during 100-thread attachment request bursts and app-server queue saturation[/+] on Sep 28, 2026
3. heznpc commented on Sep 28, 2026

   

   heznpc

   on Sep 28, 2026

   Last edited by heznpc

   More actions

   Independent macOS corroboration: ChatGPT Desktop 26.924.22138, build 11645, on macOS 27.0 / Apple Silicon / 16 GB RAM shows the same thread/attachment/list queue-saturation pattern reported here on Windows.

   The September 28, 2026 UTC logs contain 539 distinct failed request IDs, deduplicated across warning/failure entries, with -32001: App server request queue is full. This is a local JSON-RPC queue rejection, distinct from an HTTP 429 quota response. The 539 failures span historical bursts; they are not simultaneous requests or evidence of a continuous current failure.

   Associated rejection records show 4 requests in flight and 64 queued interactive requests, with priority=interactive and reason=queue-full. For example, the four-second window beginning 13:34:22 UTC includes attachment-list logs for 249 distinct conversations and 183 distinct failed requests.

   The inspected installed query handles worktree and pull-request attachment metadata and uses refetchOnMount: always. Its method name should not be interpreted as image-upload traffic. This source observation does not identify the action that triggered the bursts.

   Causal limit: these historical windows were not synchronized with UI actions or the separate renderer recording. They establish queue saturation on macOS, but do not establish its trigger or contribution to UI latency.

   Investigation request: please include macOS and trace which consumers initiate these requests, particularly mounted offscreen chat rows. Evaluate deduplication and bounded background concurrency while preserving active-chat capacity. These are investigation directions; no fix has been validated. Validate changes against both queue rejections and interaction latency with the same populated history.

   Additional burst counts — September 28, 2026 UTC

   End timestamps are exclusive. Conversation counts cover attachment-list logs; failure counts use distinct request IDs.

   UTC interval	Distinct conversations	Distinct failed requests
   13:34:22–13:34:26	249	183
   13:34:32–13:34:35	225	139
   14:25:16–14:25:17	103	36

   Only aggregate measurements are included; no raw logs, identifiers, transcripts or local paths are shared.
4. ninosat00 commented on Oct 17, 2026

   

   ninosat00

   on Oct 17, 2026 – with ChatGPT Codex Connector

   More actions

   Additional evidence: current Windows build and isolated scheduler reproduction

   The same thread/attachment/list queue saturation is still observable on Codex Desktop 26.1013.40934, build 20770, Windows, production channel. The configured updater reported up_to_date on October 17, 2026.

   Observed incident

   The October 17 startup log contains 54 queue-full rejection records for thread/attachment/list within one short burst. This is a historical incident in the sampled logs, not evidence of a continuously full queue. No new rejections were observed in the later diagnostic window. The persistent message queue was empty; it is a different queue from the client request scheduler.

   Read-only source inspection

   In this installed build, the client scheduler has an interactive backlog limit of 64. Attachment-list requests use interactive priority by default and are absent from the coalescible-method set. The inspected attachment-query call site has no shared per-host concurrency bound before admission.

   This identifies a plausible saturation mechanism. It does not establish every UI trigger or prove that all Desktop latency has the same cause.

   Controlled reproduction

   Only the installed scheduler class and its constants were extracted read-only and evaluated in an isolated JavaScript VM. No live app connection, filesystem or network access was provided to that VM. The transport was a stub: dispatch marked the request sent; completion ran on the next setImmediate callback. The requests used 200 unique synthetic IDs and method thread/attachment/list.

   Same scheduler, same synthetic workload	Succeeded	Queue-full rejections	Peak in flight
   Submit 200 requests synchronously	68	132	4
   Shared caller-side limit of 2 per host before enqueue	200	0	2

   Reproduction recipe: instantiate the scheduler, synchronously enqueue 200 distinct attachment-list operations using the stub above, await settlement, then repeat with each enqueue operation admitted through one shared two-slot limiter for the host. Both runs finish with all scheduler queues empty. This demonstrates admission overflow under a synthetic burst; it is not a UI benchmark or an end-to-end production fix.

   Separate candidate-limiter tests passed for cancellation while waiting, releasing slots after failures, and independent hosts. A real native stdio app-server also completed metadata and attachment-list reads for 24 recent/historic chats at concurrency 2, without chat or attachment writes. That stdio check bypasses the Electron scheduler and therefore does not certify Desktop recovery.

   Suggested integration and validation

   Share a small per-host limiter across attachment-page consumers, before sendRequest reaches the client scheduler. Conceptually:

   // One shared limiter, rather than one limiter per mounted query.
   return attachmentLimiter.run(hostId,
     () => sendRequest("thread/attachment/list", params, { signal }),
     { signal });

   Preserve cancellation, pagination, retries and query invalidation; keep admission protection and capacity for active-chat actions. Validate cold startup with populated history, remounted/offscreen rows and multiple windows, measuring queue rejections and interaction latency together.

   The installed signed app, admission experiments and user configuration were not modified. The limiter is a local candidate requiring vendor integration. No raw logs, chat identifiers, transcripts, account details, private configuration or personal filesystem paths are included. Prepared with Codex assistance.
5. xiru0834-eng commented on Oct 19, 2026

   

   xiru0834-eng

   on Oct 19, 2026 – with ChatGPT Codex Connector

   More actions

   October 19 recurrence: sending stalls, 1,318 queue rejections, and stale queued-submission error

   Environment: Windows x64, Codex Desktop 26.1013.40934 / build 20770, production channel; the configured updater still reported up_to_date on October 19. Backend: codex-cli 0.163.0-alpha.10.2. Follow-up messages use queue mode, which the user wants to retain.

   User impact: ordinary coding work repeatedly leaves message submission spinning; the user also reports being unable to attach/send files. Restarting temporarily restores use, but the problem recurs. There is no deterministic minimal UI trigger yet.

   Two new captured incidents (UTC, October 19, 2026)

   1. 02:26:20.609–02:29:16.173: 1,318 warning-level app_server_client_request_queue_rejected records, counted once at the rejection log rather than also counting failure echoes. Breakdown: 1,290 thread/attachment/list, 10 config/read, 6 thread/queue/list, 4 thread/list, 2 each configRequirements/read and fs/createDirectory, and 1 each fs/watch, thread/fork, app/installed, model/list. Rejections show 64 queued interactive requests and up to 8 requests in flight.
   2. 03:33:20–03:33:21: another 32 rejection warnings, all thread/attachment/list, with 64 queued interactive requests and 7 in flight. A user screenshot taken at about this time showed the pending sender. After restart, at 03:34:19.100, the desktop logged Failed to send queued message, code -32600, message queued submission not found: <redacted>.

   Sanitized excerpts (identifiers omitted):

   2026-10-19T02:26:20.609Z warning [AppServerConnection]
   app_server_client_request_queue_rejected inFlightRequestCount=8
   method=thread/attachment/list priority=interactive
   queuedInteractiveRequestCount=64 reason=queue-full
   
   2026-10-19T03:34:19.100Z warning [electron-message-handler]
   Failed to send queued message errorCode=-32600
   errorMessage="queued submission not found: <redacted>"
   

   A queued submission had been accepted before restart, and the affected conversation was independently observed starting a new turn shortly before the latter error. Thus the error suggests stale/duplicate submission state, but does not establish message loss. Please reconcile frontend queued IDs with server consumption on reconnect so the UI gives an accurate result without encouraging duplicate submissions.

   Mechanism and reproduction

   Read-only inspection of this installed build confirms the earlier comment's findings: interactive backlog limit 64; attachment-list requests absent from the coalescible-method set; attachment metadata query uses refetchOnMount: "always" and no shared pre-admission limit at the inspected call site. Cancellation is checked before/after the request but is not passed into sendRequest at that call site.

   The isolated 200-request scheduler reproduction was rerun with stub completion on the next setImmediate: 68 succeeded / 132 rejected / peak 4 in flight. Admitting the same workload through a shared two-slot per-host limiter gave 200 succeeded / 0 rejected / peak 2. Waiting cancellation, host isolation and slot release after failure also passed. This is synthetic admission-overflow evidence, not a real UI benchmark.

   A candidate integration was prepared only in a separate disposable app copy. Its full modified JavaScript passed syntax checking, but the copied client refused to launch because the native ASAR integrity check rejected it. No integrity bypass was attempted, the installed app was not patched, and no end-to-end repair is claimed. A supported vendor build is needed.

   Important boundaries and requested fix

   • thread/attachment/list handles worktree/PR metadata, not the image-upload transport. The logs establish common request-queue saturation and control-request rejection; they do not independently identify a failed image-upload network request.
   • No new native crash event was found for these two queue incidents. A separate native allocation-failure investigation belongs to Windows Codex Desktop 26.930.21537: recurring backend crash (0xc0000409) leaves app-server unavailable and active chats stalled #50324; suppressing memory extraction for one oversized history did not prevent the second queue burst.
   • Please bound/deduplicate attachment metadata fan-out before scheduler admission, preserve active-chat capacity and cancellation, validate populated-history startup/remount/multiple-window paths, and reconcile queued submissions after reconnect.
   • Please retain normal queued follow-up behavior and show actionable failure/retry state rather than an indefinite spinner. Please identify the supported build containing a fix or a supported mitigation.

   Only sanitized aggregates, technical excerpts and reproduction results are posted. No screenshot, transcript, conversation/request identifier, account detail, personal path, credential, raw log or dump is uploaded. Prepared with Codex assistance at the user's explicit request.