[Windows App] skills/list blocks thread switching for 14–22s across 29 workspaces #33236

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

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   skillsIssues related to skillsIssues related to skills

   performance

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   on Jul 15, 2026
2. github-actions commented on Jul 15, 2026

   

   github-actionsbot

   on Jul 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows/WSL2: Desktop retains one eager MCP stack per opened chat and replays history during navigation #32154
   • ChatGPT Desktop: openaiDeveloperDocs makes thread/resume take 36 seconds #32654

   Powered by Codex Action
3. zhangputing commented on Jul 15, 2026

   

   zhangputing

   on Jul 15, 2026

   Author

   More actions

   Thanks for linking these related reports. This issue overlaps with #32154 and #32654, but it is not a duplicate.

   The main difference is that this report is from a native Windows 11 environment, not WSL2 or macOS.

   In my measurements:

   • thread/resume: 60 ms
   • thread/read: 75 ms
   • skills/list: 14–22 seconds across 29 CWDs

   Therefore, the primary thread-switching delay occurs before thread/read and thread/resume. The 12.5-second mcpServerStatus/list request is a secondary issue rather than the main cause of this report.
4. cary-hu commented on Jul 15, 2026

   

   cary-hu

   on Jul 15, 2026

   More actions

   Same issue here, Each time open new session, The typing will stuck and stopped for a while.
5. NOirBRight commented on Jul 16, 2026

   

   NOirBRight

   on Jul 16, 2026

   More actions

   Additional root-cause evidence from Windows 11 x64 with Codex App 26.707.12708.0 and bundled app-server 0.144.5 (rust-v0.144.5, commit 87db9bc).

   Desktop request chain and exact cwdsCount source

   Inspection of the packaged Desktop ASAR shows this chain:

   1. WORKSPACE_ROOT_OPTIONS maps to electron-saved-workspace-roots.
   2. The workspace-root-options main-process handler returns that entire saved-root array.
   3. The default Renderer skills hook uses workspace-root-options.data.roots when no explicit CWD is supplied.
   4. It sends list-skills-for-host({ cwds: roots }).
   5. The request logger reports cwdsCount = roots.length before sending skills/list.

   Therefore:

   cwdsCount = electron-saved-workspace-roots.length
   

   It is not the active-workspace count. A Git worktree contributes only if it is persisted as a saved workspace.

   App-server duplication boundary

   The matching public source explains the near-linear amplification:

   • skills_list_response constructs a complete load for every CWD and resolves plugin skill roots inside that per-CWD loop.
   • effective_skill_roots_for_layer_stack intentionally uses the no-plugin-cache path.
   • SkillsLoadInput::new initializes plugin_skill_snapshots to None.
   • snapshot_for_cwd caches by whole CWD; a cold CWD rebuilds every selected root.
   • skill_roots adds user, system, and plugin roots for each CWD before adding the repo-local overlay.
   • load_and_merge_skill_roots reparses a plugin root when no snapshot is supplied.

   This means cold plugin roots may be parsed during capability/root discovery and then parsed again by SkillsService.

   Runtime count correlation

   A historical run with 11 saved roots reported:

   cwdsCount=11
   missingShortDescriptionCount=1304
   

   After a clean setup with one saved root, the same build reports 114-116 missing descriptions per request.

   1304 / 11 = 118.5
   

   That close match is runtime evidence that shared global/plugin skills are returned and validated once per CWD, rather than once plus a CWD-local overlay.

   Suggested implementation boundary

   • Build one immutable global/system snapshot per relevant config.
   • Build one plugin snapshot keyed by plugin ID/version/path and pass PluginSkillSnapshots into the skills load.
   • For each CWD, discover only repo-local roots and merge that overlay with the shared snapshots.
   • Add per-root singleflight so concurrent cold CWDs cannot parse the same shared root.
   • Do not gate thread switching on a cold full skills/list; stale cached data can render while an incremental refresh completes.

   This preserves normal multi-project and multi-worktree use without reducing workspace count as the solution.

   ❤️React with ❤️1Reacted by MaxZhang
6. linear

   added

   Papercuts 2026

   on Aug 6, 2026