Skip to content

Windows Desktop: Plugins page exceeds 30s timeout when scanning 60 saved workspace roots #46974

Open
Open
Windows Desktop: Plugins page exceeds 30s timeout when scanning 60 saved workspace roots#46974
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingperformanceskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

Description

@swqsldz
swqsldz
opened on Sep 21, 2026

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

  • Desktop resource/package.json version: 26.915.31945
  • Windows MSIX package: OpenAI.Codex 26.915.4065.0
  • Running bundled app-server reports: 0.155.0-alpha.9.2

These were obtained from the installed package and startup log, not from the About dialog.

What subscription do you have?

Not included in this report. The measured failure is in plugin discovery before any model inference.

What platform is your computer?

Windows 11, native Windows app-server over stdio (not WSL or Remote SSH).

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Opening the Plugins page repeatedly shows “Failed to load plugins” with:

Timeout
App server request timed out while queued

The problem also occurs after restarting the app. This profile contains 53 saved local projects with 60 distinct workspace roots.

Direct app-server measurements show that multi-directory plugin discovery takes 42–45 seconds, exceeding the desktop's 30-second request timeout, even when requesting only local marketplaces. Requests can eventually succeed after the UI has already reported failure.

Controlled comparison on the affected installation

A separate process using the same bundled executable was started with app-server --stdio, using the existing profile. After initialize / initialized, requests were issued sequentially and timed from sending the JSON request to receiving its response. No threads or model turns were started; only the diagnostic child was stopped afterward.

Request Distinct cwds Elapsed
plugin/installed 1 2.715 s
plugin/installed 21 16.860 s
plugin/installed 60 44.860 s
plugin/list, marketplaceKinds: ["local"] 1 2.166 s
plugin/list, all marketplace kinds 1 2.272 s
plugin/list, marketplaceKinds: ["local"] 60 41.658 s
plugin/installed, single-directory control after the 60-directory tests 1 2.196 s

All listed requests returned successfully with empty marketplaceLoadErrors. These are individual measurements, not benchmark averages.

During each 60-directory request, stderr emitted the same manifest warning 60 times:

target=codex_core_plugins::manifest
ignoring interface.defaultPrompt[0]: prompt must be at most 128 characters
path=file:///<CODEX_HOME>/.tmp/plugins/plugins/ngs-analysis/.codex-plugin/plugin.json

This is an observable marker of repeated manifest loading, not a claim that this particular plugin accounts for all the elapsed time.

What steps can reproduce the bug?

On the affected existing profile:

  1. Keep the saved local projects (53 projects / 60 distinct roots) and existing plugin catalog.
  2. Start or restart Codex Desktop.
  3. Open Plugins.
  4. Observe the 30-second timeout and, on subsequent attempts, the queued-timeout error.

To isolate the directory-count effect from the desktop UI:

  1. Start the bundled codex.exe app-server --stdio.
  2. Initialize with capabilities.experimentalApi = true, then send initialized.
  3. Compare these requests using one actual saved root and then all 60 actual saved roots, with otherwise unchanged configuration:
{"id":2,"method":"plugin/installed","params":{"cwds":["C:\\workspace\\project-a"]}}
{"id":3,"method":"plugin/list","params":{"cwds":["C:\\workspace\\project-a"],"marketplaceKinds":["local"]}}

Replace the example array with the actual existing directories. The exact measurements above used real saved roots; creating 60 empty directories in a fresh profile has not been tested.

Desktop log evidence

Selected fields only; timestamps are UTC and request identifiers/paths are omitted:

2026-09-21T08:35:08.303Z mcp_request_timeout method=plugin/installed timeoutMs=30000
2026-09-21T08:35:08.440Z mcp_request_timeout method=plugin/list timeoutMs=30000
2026-09-21T08:35:08.442Z code=-32000 message="App server request timed out after dispatch"
2026-09-21T08:35:17.579Z response_routed method=plugin/installed durationMs=39278 errorCode=null

The last line is the eventual successful response to the timed-out installed-inventory request. Other requests sometimes complete quickly; this is not a permanently unresponsive server.

What is the expected behavior?

The Plugins page should remain usable with dozens of saved projects. Shared plugin metadata should not require enough repeated work across workspace roots to exceed the UI deadline.

Ideally, load/cache common marketplace manifests once and merge directory-specific configuration separately, or batch discovery with progress/partial results. A timeout should not leave retries unusable while earlier requests are still completing.

Additional information

Read-only inspection of the shipped desktop JavaScript is consistent with the measurements:

  • getWorkspaceRootOptions collects roots from all saved local projects.
  • Plugin inventory queries pass these roots as cwds; the catalog query can additionally include an internal marketplace directory.
  • The relevant desktop requests have a 30,000 ms timeout.
  • The request manager tracks up to two timed-out, still-outstanding plugin/list requests; while that limit is reached, a subsequent request can be rejected before dispatch with the queued-timeout message.

This points to repeated discovery across roots as a sufficient trigger on this installation. It is not a source-level CPU/lock profile of the Rust implementation, and it does not rule out other latency sources.

The existing profile includes custom MCP servers and local model-provider proxy configuration. A clean profile/default-provider comparison has not been performed. The diagnostic requests did not invoke model inference.

A separate fast plugin/read error for the unavailable record-and-replay bundled plugin also appears on Windows, but it is not established as the cause of these slow list requests.

Possibly related: #33236 (multi-workspace skills/list latency), #46479 (Windows request-queue expiration). This report adds direct plugin/installed and local-marketplace plugin/list timing comparisons against directory count. Please consolidate if this is the same underlying defect.

No raw logs, credentials, project names, local user paths, or conversation contents are attached.

Activity

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

  2. Lianye-Scythe commented on Oct 3, 2026

    @Lianye-Scythe
    Lianye-Scythe
    on Oct 3, 2026 – with ChatGPT Codex Connector

    Additional reproduction: Windows Desktop with WSL, 15 saved roots, on 26.930

    I am seeing the same Plugins-page timeout symptom on a newer Windows Desktop build, with a smaller saved-project inventory and a WSL-backed app-server. This is additional evidence for #46974; I have not established that the underlying cause is identical.

    Environment

    • Observation date: 2026-10-03 (Asia/Taipei); log timestamps below are UTC.
    • Codex Desktop app.asar package version: 26.930.31428.
    • Installed Windows MSIX package version: 26.930.3748.0.
    • WSL app-server executable identified in the desktop startup log: codex-cli 0.160.0 (--version checked on that executable).
    • Windows 11, version 10.0.26300, build 26300, x64.
    • WSL2 kernel: 6.18.40.1-microsoft-standard-WSL2, x86_64.
    • Startup logs show spawnCommand=wsl.exe and transport=stdio for the local app-server.
    • Persisted desktop state contains 17 local-projects entries and 15 distinct electron-saved-workspace-roots. These are inventory counts, not a verified count of cwds passed to an individual request.
    • Six custom MCP server entries are configured. The user configuration does not select a custom model provider; features.remote_plugin is not explicitly set. A clean-profile comparison has not been performed.
    • Subscription: not collected.

    Versions were read from the installed package/executable, not the About dialog.

    Actual behavior and reproduction

    On this existing profile:

    1. Start Codex Desktop.
    2. Open Customize → Plugins → Public.
    3. The main pane shows 外掛程式載入失敗 (Failed to load plugins), with Timeout underneath. The Installed sidebar remains on loading placeholders.
    4. Retry/refresh or fully restart the app. The user reports that these did not resolve the problem; changing networks/VPN/proxy conditions also did not resolve it. The latter is user-reported troubleshooting, not an instrumented network comparison.

    The desktop log records plugin/list and plugin/installed requests reaching a 30,000 ms timeout. Several installed-inventory responses later arrive successfully with errorCode=null, after the UI deadline has elapsed.

    Matched-request log evidence

    Each timeout/response pair below was matched using the same original request ID. IDs are replaced with A/B/C; only selected diagnostic fields are reproduced.

    2026-10-03T02:18:56.278Z mcp_request_timeout method=plugin/installed timeoutMs=30000 request=A
2026-10-03T02:19:09.755Z response_routed method=plugin/installed durationMs=44262 errorCode=null queueWaitMs=0 request=A

2026-10-03T02:19:27.280Z mcp_request_timeout method=plugin/installed timeoutMs=30000 request=B
2026-10-03T02:19:45.193Z response_routed method=plugin/installed durationMs=48874 errorCode=null queueWaitMs=0 request=B

2026-10-03T02:33:56.277Z mcp_request_timeout method=plugin/installed timeoutMs=30000 request=C
2026-10-03T02:34:17.999Z response_routed method=plugin/installed durationMs=52509 errorCode=null queueWaitMs=1 request=C

2026-10-03T02:29:09.883Z mcp_request_timeout method=plugin/list timeoutMs=30000
2026-10-03T02:29:09.886Z code=-32000 message="App server request timed out after dispatch"

    Other plugin/installed requests in the same desktop run complete in approximately 2 seconds. A different plugin/list request succeeds in 15.489 seconds at 02:30:07.365Z; this is not the late response to the timed-out list request above. The server is intermittently slow rather than permanently unresponsive.

    The same startup log also records three Local Work executor startup attempts failing with Timed out waiting for MCP response to plugin/installed. Their relationship to the Plugins-page failure has not been isolated.

    Expected behavior

    The Plugins page should reliably load both the catalog and installed inventory on this profile. Requests that eventually succeed should not leave the UI displaying a timeout indefinitely; retry/recovery should remain usable.

    Scope and diagnostic limits

    • This confirms the 30-second UI deadline / late-success failure pattern. It does not prove repeated scanning across workspace roots is the cause here.
    • No controlled single-root versus all-roots app-server comparison has been run on this installation.
    • No CPU/lock profile, clean-profile test, or native-Windows-versus-WSL comparison has been performed.
    • No settings or plugin caches were modified during evidence collection.
    • The failure occurs in plugin discovery; no model token/context limits are implicated by the collected evidence.
    • Raw logs and the screenshot are omitted to avoid exposing unrelated data. Credentials, original request IDs, project names, user paths, MCP endpoints, and conversation contents are excluded.

    Related report: #46974

  3. ASPMNV commented on Oct 6, 2026

    @ASPMNV
    ASPMNV
    on Oct 6, 2026

    Windows Codex Desktop 26.930.4958.0: messages repeatedly stayed queued until restart. One of 29 saved project roots was an unavailable network-drive folder, included in background plugin/installed requests. Logs showed seven consecutive timeouts.

    Removing that project registration and restarting restored sequential sending: four messages succeeded without another restart, and plugin timeouts disappeared during the observed interval. Project files and chat history were preserved. Long-term stability is not yet verified.

    Please investigate whether unavailable saved roots can block unrelated chats.

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 workingperformanceskillsIssues 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