Windows Desktop: Opening Plugins saturates app-server queue and causes subsequent message sends to time out

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

26.803.5235.0

What subscription do you have?

ChatGPT Pro 5x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Codex Desktop for Windows, opening the Plugins page can saturate the local app-server request queue. The Plugins page eventually fails with:

Failed to load plugins
App server request expired while queued

After this happens, normal Codex messages also stop sending and eventually time out. Fully restarting the desktop app restores message sending until Plugins is opened again.

Opening Plugins initiates plugin discovery/reconciliation and other relatively long-running requests. External-agent detection timeouts were observed in the original logs, but subsequent isolation shows they are not established as the sole root cause.

Latest isolation

The original issue reproduced using the native Windows backend. Further testing using the WSL backend found:

1. features.apps = false, features.plugins = false

• Message sending works normally.

1. features.apps = false, features.plugins = true

• Every named plugin was explicitly set to enabled = false.
• Opening Plugins and then sending a message still reproduced the hang.
• Therefore, the failure does not require a particular enabled plugin.

1. features.apps = true, features.plugins = false

• Apps load successfully.
• Message sending remains stable.
• thread/start and turn/start complete without queue rejection.

This isolates the trigger to the global plugin framework / Plugins UI path rather than the Apps framework, authentication, general network access, sandbox elevation, or one particular enabled plugin.

With the plugin framework enabled, startup also scanned plugin content under .codex/.tmp/plugins/ despite every named plugin being disabled. In the affected run, skills/list took approximately 25 seconds and experimentalFeature/list took approximately 24 seconds, placing both close to the desktop's 30-second queue timeout.

Current workaround

No plugins were uninstalled. Only the global plugin feature gate is disabled:

[features]
apps = true
plugins = false

What steps can reproduce the bug?

1. Launch Codex Desktop on Windows.
2. Open any existing Codex conversation.
3. Send a simple message such as test.
4. Confirm that the message sends normally.
5. Open the Plugins page.
6. Wait for Plugins to load.
7. After approximately 30 seconds, Plugins reports:

``text
Failed to load plugins
App server request expired while queued
``

1. Return to the conversation and send another simple message.
2. The message hangs and eventually fails with a timeout.
3. Fully quit and restart Codex Desktop.
4. Send a message without opening Plugins; it works normally again.
5. Open Plugins again; the issue reproduces.

The feature-gate isolation above provides a minimal variant: the failure still reproduces with Apps disabled and every named plugin disabled, as long as the global Plugins feature is enabled.

No code snippet is required; opening the Plugins page is the trigger.

Relevant logs

Before opening Plugins, requests complete normally, including plugin/list, config/read, thread/read, and turn/start.

In the original run, external-agent discovery timed out for Cursor and Claude Code:

Timed out waiting for MCP response to externalAgentConfig/detect

The app-server then reached its in-flight limit and started rejecting queued requests:

app_server_client_request_queue_rejected
inFlightRequestCount=6
method=plugin/list
reason=queue-expired

This was followed by:

App server request expired while queued

Queue starvation then affected unrelated methods, including:

• mcpServerStatus/list
• model/list
• config/read
• thread/list

Eventually message submission failed:

[Composer] submit failed ... errorMessage=Timeout
App server request timed out after dispatch

Additional diagnostics

• In-app feedback session ID for diagnostic correlation: no-active-thread-019fdcdc-a067-7f63-99c0-7029264ef97c
• Direct Codex CLI requests succeeded, ruling out authentication and general network failure.
• Switching from the Windows elevated sandbox to the unelevated sandbox did not resolve the message timeouts.
• After switching the desktop agent to WSL and repairing a separate stale SQLite backfill, the queue starvation still reproduced.
• A complete clean reinstall/reset worked normally until Plugins was opened.
• The desktop UI remains responsive during the failure.
• The issue reproduces across conversations with a simple test prompt and is not related to context-window usage.
• Restarting immediately clears the condition.

Related queue-starvation reports with different triggers are #36914 and #36189. Those involve thread/collaboration hydration rather than the Plugins UI/plugin framework, but may share the same app-server scheduling or backpressure weakness.

What is the expected behavior?

A slow or failed Plugins request should remain isolated. Plugin discovery/reconciliation should not occupy every app-server request slot or block interactive operations such as thread/start, turn/start, and message submission.

Background plugin work should be cancellable, coalesced, or lower priority than interactive requests, and a Plugins-page failure should not require restarting the desktop app.

Additional information

<img width="967" height="573" alt="Image" src="https://github.com/user-attachments/assets/ca2b248f-9a20-433a-afeb-00487412ce4e" />