[Windows Desktop][26.803.10989.0] Six stuck app-server requests freeze every window and remove Fast mode

What version of the Codex App are you using (from the About dialog)?

OpenAI Codex Windows package 26.803.10989.0 (x64), bundled backend codex-cli 0.147.0-alpha.6.6.

What subscription do you have?

ChatGPT sign-in. Exact plan is omitted because the failure occurs in the local Desktop/app-server transport before a model turn starts.

What platform is your computer?

Windows 11 Pro 25H2, build 26200.9168, x64.

What issue are you seeing?

All open Codex Desktop windows intermittently stop receiving app-server data at the same time. Existing tasks stop updating, new sends time out, and model/config-dependent UI stops populating. In particular, Speed -> Fast disappears from the model menu. Fully quitting and restarting Codex immediately restores every window and makes Fast selectable again under the same account.

This reproduced twice on 2026-08-13. Sanitized renderer-log evidence from the two independent app sessions:

Incident 1
11:42:06Z config/read rejected after queue expiry, inFlightRequestCount=6
11:42:08Z model/list rejected after queue expiry
11:42:13Z critical turn/start timed out
11:43:39Z another turn/start timed out

Incident 2
13:30:55Z model/list rejected after queue expiry, inFlightRequestCount=5
shortly afterward inFlightRequestCount reached 6
plugin/list, skills/list, and thread/list then expired while queued
13:32:20Z critical turn/start timed out

Representative sanitized signature:

app_server_client_request_queue_rejected
method=config/read
priority=critical
inFlightRequestCount=6
reason=queue-expired

mcp_request_timeout method=turn/start timeoutMs=30000

The Fast-menu symptom appears to be downstream, not an entitlement change: model/list and config/read cannot cross the saturated local queue, and a restart restores the option without any account change.

Both incidents occurred while the same collaboration-heavy task was coordinating multiple subagents. A structural-only trace (no task text or identifiers) shows:

Incident 1: spawn_agent at 11:41:07Z -> no parent-task events during the stall -> activity resumes after restart
Incident 2: spawn_agent at 13:29:32Z, wait_agent at 13:29:38Z -> model/list expires at 13:30:55Z -> turn/start times out at 13:32:20Z -> activity resumes after restart

This makes subagent/collaboration concurrency a likely trigger or amplifier, but does not prove that a particular subagent request is the original hung request.

There was also an unusually large untracked dependency backup in the working tree during the first incident: 20,249 files and approximately 3.1 million added lines entered a turn snapshot, with one emitted diff event around 59 MB. Excluding that already-preserved directory from local Git enumeration reduced the untracked snapshot surface to 307 files. That load may help trigger the stall, but it does not explain why already-dispatched requests retain all six scheduler slots indefinitely.

Installed-bundle diagnosis

Inspection of the installed, version-specific Desktop JavaScript bundle suggests the following failure path:

• One app-wide scheduler is shared by all windows and has a maximum of six dispatched requests (the installed minified bundle uses eU=6; the background threshold is tU=5).
• Once six requests have been marked sentToTransport, getNextRequestIndex stops dispatching anything else.
• The renderer's 30-second MCP timeout rejects the caller, but does not appear to cancel or remove an already-dispatched scheduler entry.
• dropUnsentRequest removes only requests that have not yet been sent to the transport.
• If six dispatched app-server calls never complete, the queue remains permanently full. Later model/list, config/read, thread/list, plugin/skill discovery, and even critical turn/start calls queue and expire.

That model matches both observed sessions and explains why every Desktop window fails together and why a full restart is curative.

What steps can reproduce the bug?

The trigger is intermittent, but it reproduced twice within about two hours with this pattern:

1. Open multiple Codex Desktop windows.
2. Keep a collaboration-heavy task active and coordinate multiple subagents using repeated spawn, follow-up, message, and wait operations.
3. Continue switching tasks or sending work from other windows. A very large working-tree snapshot was present in one observed incident.
4. When six dispatched app-server requests stop completing, observe that every window stops updating and later requests expire.
5. Open the model menu: Fast is missing because model/config metadata cannot load.
6. Fully quit and restart Codex Desktop. Windows resume and Fast reappears immediately.

I do not yet have a deterministic minimal reproducer.

What is the expected behavior?

• A dispatched app-server request needs a bounded watchdog/cancellation path that always releases its scheduler slot.
• If the child app-server or transport stops completing requests, Desktop should recycle that connection/process automatically rather than leave six permanent in-flight entries.
• Critical turn/start, config/read, and model metadata traffic should not starve behind background collaboration/history work.
• A failure initiated by one task must not disable every window that shares the Desktop backend.
• The UI should preferably retain last-known model/speed metadata while a refresh is temporarily unavailable, rather than making Fast appear to have been revoked.

Additional information

• savedRemoteConnectionCount=0; this is not the unavailable-SSH-host path described in #35733.
• The machine was not under system memory pressure during either incident.
• There was exactly one official packaged Desktop root and one packaged child app-server. Separate VS Code and task-specific app-server processes were present but had different parents and executable locations.
• No raw logs or screenshots are attached because they contain task names, local paths, and conversation identifiers. Targeted redacted excerpts can be provided if maintainers request them.
• Temporary local workaround: restart Codex Desktop. A conservative local watchdog now detects only the exact six-slot-plus-turn/start signature and restarts the packaged child app-server, with a full packaged-app restart only as fallback.

Possibly related, but not exact duplicates: #36914 (collaboration hydration starvation), #23644 (stale conversation state and six-slot queue expiry), #27395 (sidecar stalls and turn/start timeouts), #37775 (active Windows turns stop showing progress), and #35782 (Windows app-server recovery under concurrent tasks).

Start by tracing the app-wide scheduler around getNextRequestIndex, dropUnsentRequest, sentToTransport, and the renderer MCP timeout in the installed Desktop bundle. Reproduce the six-slot queue-expiry pattern with the reported collaboration-heavy workflow and inspect whether dispatched requests remain after timeout. Done means stalled requests no longer permanently consume slots, critical calls recover, and model/config metadata returns without requiring a full restart.