Windows app UI stutters while opening a project; possible synchronous discovery of “Open in” IDEs

Open 💬 1 comment Opened Jul 29, 2026 by Jiuxiao-yunwai
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Windows package version: 26.721.11231.0

What subscription do you have?

Not relevant / not provided.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Windows desktop app noticeably stutters while the app/project is opening, even when no agent task is running.

A possible contributor is synchronous or repeated discovery of applications that can open the current project. The Open in dropdown is populated with multiple locally detected targets on this machine:

  • VS Code
  • Visual Studio
  • Antigravity
  • File Explorer
  • Terminal
  • WSL
  • PyCharm

This is only a hypothesis based on the observed UI and timing, not a confirmed root cause. If Codex checks the registry, filesystem, executable availability, WSL status, or launches probe processes for every supported target during startup/project loading, doing that work on the Electron main/renderer-critical path could explain the UI stalls—especially on Windows, where some probes can be slow.

What steps can reproduce the bug?

  1. Install and launch the Codex desktop app on Windows.
  2. Open a local project/workspace.
  3. Observe the UI while the application and project are loading.
  4. Notice visible stuttering/temporary unresponsiveness even though no agent task is running.
  5. Open the dropdown next to the top-right terminal/open button.
  6. Observe that Codex has discovered several IDE, shell, file-manager, and WSL targets listed above.

Observed on this machine. I do not yet have a performance trace proving that target discovery is responsible.

What is the expected behavior?

Opening Codex and loading a project should remain responsive.

Discovery of external openers should ideally be:

  • lazy (performed when the dropdown is opened),
  • cached between renders/sessions where appropriate,
  • asynchronous and off the UI-critical path,
  • protected by short timeouts, especially for WSL and executable probes.

Additional information

Please consider instrumenting the startup/project-open path with per-target timings to determine whether IDE/File Explorer/Terminal/WSL detection is blocking or being repeated unnecessarily.

A screenshot of the dropdown shows the detected entries listed above. The screenshot can be provided if needed.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 29 days ago

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

  • #35697
  • #35314
  • #35538

Powered by Codex Action