Skip to content

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

Open
Open
Windows Desktop: Opening Plugins saturates app-server queue and causes subsequent message sends to time out#37401
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

Description

@CK-XYZ
CK-XYZ
opened on Aug 7, 2026

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.
  2. 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.
  3. 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: 
    Failed to load plugins
App server request expired while queued
  8. Return to the conversation and send another simple message.
  9. The message hangs and eventually fails with a timeout.
  10. Fully quit and restart Codex Desktop.
  11. Send a message without opening Plugins; it works normally again.
  12. 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

Image

Activity

  1. CK-XYZ
    added
    appIssues related to the Codex desktop app
    on Aug 7, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    skillsIssues related to skills
    on Aug 7, 2026

  3. github-actions commented on Aug 7, 2026

    @github-actions
    github-actionsbot
    on Aug 7, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. CK-XYZ commented on Aug 7, 2026

    @CK-XYZ
    CK-XYZ
    on Aug 7, 2026
    Author

    Update after further diagnostics:

    The original queue-starvation report remains valid, although external-agent
    discovery may not be the sole root cause.

    • The Windows elevated sandbox setup had an unrelated ACL failure, but switching
      to the unelevated sandbox did not resolve message timeouts.
    • Direct Codex CLI requests succeeded, ruling out authentication and general
      network failure.
    • I switched the desktop agent to WSL and repaired a separate stale SQLite
      backfill. With apps/plugins enabled, the desktop still reached its in-flight
      request limit and thread/start timed out.
    • Setting features.apps = false and features.plugins = false, while leaving
      plugins installed, stopped the queue starvation and restored message sending.

    Therefore the issue appears to remain in the desktop app/plugin request path.
    Disabling apps/plugins is currently a workaround rather than a fix.

  5. CK-XYZ commented on Aug 7, 2026

    @CK-XYZ
    CK-XYZ
    on Aug 7, 2026
    Author

    Additional isolation results for Codex App 26.803.5235.0:

    I tested the global Apps and Plugins feature gates independently.

    Results

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

      • Message sending works normally.

    2. 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.

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

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

    This narrows the problem to the global plugin framework / Plugins UI path,
    rather than the Apps framework or one specific enabled plugin.

    With the plugin framework enabled, startup also scanned plugin content under
    .codex/.tmp/plugins/ despite all named plugins being disabled. skills/list
    took approximately 25 seconds and another feature request took approximately
    24 seconds, placing them close to the desktop's 30-second queue timeout.

    Current workaround:

    [features]
apps = true
plugins = false

No plugins were uninstalled; only the plugin feature gate is disabled.

  6. Miles-Cheverton commented on Sep 14, 2026

    @Miles-Cheverton
    Miles-Cheverton
    on Sep 14, 2026

    Sharing a recovery observation from my macOS report #45405 because it showed a similar inFlightRequestCount=6 / App server request expired while queued pattern affecting unrelated RPCs and message submission.

    On my Mac Studio, I turned Allow Connections OFF in ChatGPT Desktop, waited a few seconds, then turned it ON again. Local Work started working again. App/runtime restarts, disabling user MCP servers and a completely fresh CODEX_HOME had previously failed to restore it.

    Environment: ChatGPT 26.908.40834 (8881), bundled Codex 0.154.0-alpha.6.2, macOS 27.0 build 26A428, arm64. No OS downgrade was needed.

    This recovery is confirmed in my environment. It is not a verified Windows fix or proof that the incidents share a cause. Plugin reconciliation appeared in my logs, but I have not established it as the trigger. Full details: #45405.

  7. MisterRound commented on Sep 19, 2026

    @MisterRound
    MisterRound
    on Sep 19, 2026

    Reproduced again on the current Windows Store build, with a more specific split between healthy installed capabilities and the failing directory path.

    Current build

    • AppX: 26.915.4065.0
    • Desktop client: 26.915.31945
    • WSL app-server/agent: 0.155.0-alpha.9.2

    Current behavior

    1. The installed-plugin row renders successfully.
    2. Installed plugin tools and skills are actually available to tasks; this is not an installation or tool-exposure failure.
    3. The Skills page eventually renders, but took roughly 35 seconds in this reproduction.
    4. The public Plugins directory remains on skeletons and then reports Failed to load plugins / Timeout at the client's 30-second request limit.
    5. Navigating back to a task does not stop the work. The same Desktop connection continued issuing a new unpaginated plugin/list approximately every 30 seconds. I observed 15 consecutive requests at an exact 30.0-second mean interval after leaving the page.
    6. During this bounded observation, ordinary task traffic still completed and no queue-rejection event was logged yet. This is therefore an active retry/load condition with the same starvation risk as the original report, not proof that the queue was already saturated in this run.

    The fresh global remote-catalog cache under <CODEX_HOME>/cache/remote_plugin_catalog is 23,230,589 bytes and contains 4,529 plugin summaries. The current Desktop renderer still uses full plugin/list for the directory and applies a 30-second client timeout. The protocol already exposes paginated plugin/search, while plugin/installed provides the much narrower installed inventory without fetching the broader catalog.

    I also tested the apparent features.remote_plugin=false escape hatch without persisting it. It changes the effective installed inventory to legacy local curated copies and drops remote-only/default inventory in this environment, so it is not an installed-capability-preserving fix.

    This now looks closely related to the payload-size evidence in #41573, although this reproduction is local Windows Desktop + WSL rather than Remote SSH. The merged plugin discovery work in #46558, #46567, and #46572 is useful agent/runtime architecture, but none of those changes directly replaces the Desktop directory's full plugin/list request.

    Requested product-side correction

    • Render the installed section from plugin/installed.
    • Load the public directory through paginated plugin/search rather than returning the entire global catalog in one plugin/list response.
    • Cancel or coalesce timed-out directory requests and stop retrying them after the route is no longer visible.
    • Keep background catalog work lower priority than interactive task RPCs.
    • Avoid treating a 30-second client timeout as a trigger to start another full request while the previous server work can still be running.

    No plugins were removed or disabled for this reproduction.

  8. MisterRound commented on Sep 19, 2026

    @MisterRound
    MisterRound
    on Sep 19, 2026 – with ChatGPT Codex Connector

    Reproduced again on 26.915.4065.0, this time with evidence that paginated plugin/search itself can starve behind unrelated startup work.

    After a fresh restart, typing deep in Plugins issued three plugin/search requests. All three expired after about 30 seconds with:

    inFlightRequestCount=5
method=plugin/search
priority=interactive
reason=queue-expired
App server request expired while queued

    This was not caused by a slow full-catalog response in that moment:

    • plugin/list completed in 10,340 ms, including 8,710 ms of queue wait.
    • Concurrent thread/search calls occupied app-server capacity for 34,231 ms, 66,671 ms, and 67,806 ms.
    • Additional thread/search calls later completed after roughly 228-267 seconds, some with 29-62 seconds of queue wait.

    So replacing the directory's unpaginated plugin/list with plugin/search is necessary but not sufficient. Interactive search still has no usable lane when startup/history searches monopolize all five in-flight slots.

    Suggested scheduler-level invariants:

    • Reserve capacity for interactive requests or allow them to preempt/cancel background startup work.
    • Treat startup thread/search hydration as bounded/background work.
    • Debounce and coalesce incremental plugin-search requests while typing.
    • Cancel queued and in-flight page requests when the route changes.
    • Do not let one request family consume every app-server slot for minutes.

    No plugins were removed or disabled for this reproduction.

  9. kzkvv commented on Sep 25, 2026

    @kzkvv
    kzkvv
    on Sep 25, 2026

    Met the same bug. It's really annoying - each ~30 min codex is stuck -> time is lost, job is not done :(
    Asked codex in the separate console to investigate this issue with codex app - codex found a few issues, this one looks most relevant.
    Plugins are necessary for me, so disabling them is not an option.
    Will post a workaround if'll found one.

  10. grtninja commented on Oct 3, 2026

    @grtninja
    grtninja
    on Oct 3, 2026 – with ChatGPT Codex Connector

    Additional Windows desktop UI symptom from October 2: the owner observed 'Failed to load plugins' on the Plugins page and 'Loading skills' in the Skills interface. Connector calls working in the assistant did not verify recovery of the owner's Plugins/Skills UI or explicit invocation path.

    We have not captured the queued-request error, request timings or queue occupancy for this occurrence. This is corroboration of the visible symptom, not confirmation of the original report's queue-starvation cause. Which supported diagnostic separates local discovery/queue delay from a remote catalog error while preserving installed capabilities?

    -DOTS

  11. MisterRound commented on Oct 13, 2026

    @MisterRound
    MisterRound
    on Oct 13, 2026

    Fresh reproduction on Windows Store package 26.1007.2314.0 / Desktop 26.1007.21434, with WSL agent 0.162.0-alpha.17.2, on October 13.

    This time the installed sidebar's narrower plugin/installed request failed, not just full-catalog plugin/list:

    • The interactive queue reached 64 entries with 4-6 requests in flight.
    • plugin/installed expired after about 30 seconds waiting in the queue.
    • plugin/read was also rejected with App server request queue is full.
    • In the same interval, several thread/search calls ran for 256-259 seconds after roughly 522-524 seconds queued; another took 795,475 ms plus 11,577 ms queued.
    • One plugin/read finally succeeded in just 737 ms after 656,669 ms of queue wait.
    • After the backlog drained, plugin/installed completed in 394 ms with zero queue wait; later checks completed in 1,941 ms and 232 ms, also with zero queue wait.

    The user retried and the load-error banner cleared without restarting Desktop, disabling plugins, changing configuration, or reinstalling anything. The current installed renderer already uses plugin/installed for installed inventory, but that request is background-priority and can still starve behind long history searches.

    This reinforces the scheduler-level part of the September 19 follow-up: narrower inventory and paginated search do not by themselves prevent unrelated long-running requests from monopolizing capacity. Bounded/cancellable history search, request coalescing, and starvation prevention are still needed.

    No private conversation IDs, plugin IDs, account details, local paths, or raw logs are included. A separate plugin icon-metadata defect was isolated independently and is not being attributed to queue starvation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions