Windows Desktop app discovery synchronously blocks the Chromium UI thread during cold + and Open in... lookups

Environment & System Details

• OS: Windows 11 Pro (Build 10.0.26300, 64-bit)
• Codex Desktop (Microsoft Store / MSIX): 26.715.8383.0
• Previous affected Codex Desktop build captured with Procmon: 26.715.7063.0
• Standalone Codex CLI: 0.144.6 (%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe)
• Computer Use / Browser / Chrome runtime bundle: 26.715.61943
• Chrome: 150.0.7871.129

---

1. Impact and Symptom Summary

Codex Desktop performs Windows desktop-application metadata discovery on a path that can synchronously block the main Chromium UI thread while a PowerShell child process is being created.

Two user-visible cold-path symptoms were measured:

1. Primary — New chat (+): with computer-use@openai-bundled enabled, the first cold + click freezes the complete app (Responding=False) for approximately 15–20 seconds. Once the lookup has completed, later + clicks in the same warm session are normally immediate.
2. Secondary — Open in... target discovery: the first cold opening of the file-target menu remains on Loading available apps... for approximately 60 seconds before application targets appear. A second opening immediately afterward is instant. This strongly suggests another cached desktop-app discovery path, but this secondary symptom has not yet been captured with its own dedicated process trace.

The UI freeze is disruptive because it occurs in basic navigation before Computer Use is invoked. The affected user wants to keep Computer Use enabled, so disabling the plugin is a diagnostic control and workaround, not an acceptable permanent solution.

---

2. Reproduction

Primary + freeze

1. Install or enable computer-use@openai-bundled.
2. Fully exit Codex Desktop, including its helper processes.
3. Start Codex Desktop normally (not elevated).
4. Return to an existing task before using Computer Use or other plugins.
5. Click + once to open the new-chat menu.

Expected: the menu appears immediately and the Chromium UI remains responsive.

Actual: the complete Codex window becomes Responding=False for approximately 15–20 seconds. The menu then appears and later warm clicks usually work immediately.

Secondary Open in... delay

1. After a cold Codex Desktop start, open the menu for a local Markdown file.
2. Select Open / Open in... and watch the available-target area.
3. Close and immediately reopen the same menu after it eventually populates.

Actual: the cold lookup remains on Loading available apps... for approximately 60 seconds; the warm repetition is immediate.

---

3. Controlled Result Matrix

| Test | Controlled change or observation | Result | Interpretation |
|---|---|---|---|
| Unfiltered Procmon capture, manual cold + click | No configuration change | Main app stopped responding while it synchronously launched a PowerShell metadata-discovery child | Direct process correlation |
| Disable only the Computer Use skill, leave plugin installed | Skill toggle only | First click still took roughly 20–30 seconds; later clicks were warm and fast | Disabling only the skill is insufficient |
| Disable the complete Computer Use plugin and restart | Plugin toggle only | + opened immediately in 3/3 tests, including the first cold click | Working workaround and strong plugin-path isolation |
| Updated Desktop build with Computer Use disabled | Store update only; plugin remained disabled | Five observed post-update checks were immediate, including a check after a full cold restart | Disabled-path baseline remained healthy |
| Enable Computer Use on build 26.715.8383.0 | Only intended variable was enabled: false -> true; Browser, Chrome, firewall state, notify, and Node REPL were unchanged | First cold + click froze for approximately 15 seconds; warm behavior recovered | A-side reproduction |
| Disable Computer Use again and restart | Rollback of the same plugin toggle | Tool host recovered and the next + check was immediate | A/B/A relationship confirmed for this session |
| Remove and cleanly reinstall only Computer Use | Plugin state/cache quarantined; official CLI removal/reinstall; app regenerated managed fields | Plugin was healthy and functional, but the first cold + click still froze for approximately 20 seconds | Stale Computer Use plugin cache is not sufficient to explain the problem |
| Rebuild the complete shared CUA/Browser/Chrome/Node runtime | Computer Use, Browser, Chrome, Node REPL, cua_node, both Codex temp directories, and related state/cache rebuilt | Health checks passed and Node REPL was fast, but first cold + still froze for approximately 15 seconds | Old shared runtime or temp state is not the standalone cause |
| Browser control after rebuild | Isolated example.com test | Backend attach ~0.6 s, tab 765 ms, navigation ~1.37 s, DOM snapshot 110 ms | In-app Browser path was healthy |
| Chrome-extension control after rebuild | Isolated example.com test in a newly opened tab | Extension attach ~0.7 s, tab 104 ms, navigation ~1.01 s, DOM snapshot 408 ms | Chrome extension path was healthy once Chrome was running |
| Cold and warm Open in... check | No configuration change | Cold ~60 s on Loading available apps...; immediate when repeated warm | Strong evidence of cached application-target discovery; exact child process not yet traced |

---

4. Procmon and WinDbg Evidence

During a clean, broad Procmon capture of one manually reproduced + hang on Desktop build 26.715.7063.0:

• The Codex/ChatGPT main process began resolving C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe and then stopped producing its own I/O events.
• A PowerShell child was created with the Codex main process as its parent.
• Across all 32 captured process-profile samples, that PowerShell child remained at 0.000 s CPU, approximately 405 KB private bytes, and no observed child I/O.
• Its command line used:

``text
-NoProfile -NonInteractive -ExecutionPolicy Bypass -EncodedCommand <multi-kilobyte payload>
``

• conhost.exe did not appear under that child until more than 73 seconds after child creation. The PowerShell process exited several seconds later.
• Windows Error Reporting subsequently launched for the non-responsive main process.
• A WinDbg trace captured the main Chromium thread (CrBrowserMain) waiting synchronously in:

``text
NtCreateUserProcess
-> CreateProcessInternalW
-> CreateProcessW
-> chrome!uv_spawn
``

Inspection of the packaged application code tied this invocation to a routine named/described as Windows native desktop app metadata lookup. The sanitized decoded script enumerates metadata from Get-StartApps, UserAssist, active processes, and usage ranking.

This proves the UI-thread wait and its correlation with the PowerShell metadata child. It does not by itself identify which Windows or endpoint-security component causes the unusually slow process initialization.

---

5. Command-Line Size Isolation

The metadata lookup was then isolated outside Codex with privacy-safe probes and the sanitized application payload. No persistent system settings were changed.

| Probe | Approximate command-line size | Time / outcome |
|---|---:|---|
| Individual metadata components (Get-StartApps, process enumeration, sanitized UserAssist logic) | Short | 0.39–0.95 s each |
| Harmless encoded payload | 965 characters | 2.36 s |
| Harmless encoded payload | 1,915 characters | 7.62 s |
| Harmless large encoded payload | approximately 8,185 characters | >10 s |
| Full sanitized Codex payload through -EncodedCommand | approximately 8,200 characters | Did not reach its first-script-line marker during the measured stall; matches the observed 15–20 s UI-freeze range |
| Exact same full script body through stdin using powershell.exe -Command - | Short command line | No measurable pre-script delay; 2.008 s total, exit code 0, 167 result items, no stderr |

The important distinction is where the delay occurs:

• The metadata operations themselves complete quickly when run separately.
• Runtime increases sharply with command-line length even for privacy-free harmless payloads.
• The long encoded application payload can stall before the first script marker.
• Passing the exact same script body through stdin removes the pre-script spawn stall and completes normally.

This demonstrates that the script contents and metadata queries are not required to reproduce the delay. A sufficiently large PowerShell command line is enough on this system.

---

6. Controls, Negative Results, and Rebuilds

The following possible explanations were tested or bounded:

• Computer Use skill toggle only: insufficient; the cold delay remained because the plugin/runtime path stayed installed.
• Complete Computer Use plugin disabled: reliable workaround during the controlled checks.
• Store app update: did not solve the active Computer Use path. With Computer Use disabled, + was immediate; enabling the updated runtime reproduced the cold freeze.
• Computer Use cache corruption: a clean remove/reinstall regenerated the plugin and managed configuration successfully, but the cold freeze still occurred.
• Shared Node/CUA runtime corruption: the Node runtime, Computer Use state, Browser/Chrome caches, marketplace/temp directories, and Node REPL were rebuilt. Health checks passed; the freeze remained.
• Node REPL generally slow: after the clean rebuild, the regenerated Node REPL responded in approximately 0.1–1.1 seconds while the + freeze still reproduced.
• Browser or Chrome generally broken: both completed isolated page-navigation/DOM tests quickly after rebuild.
• Codex Document Control: disabling it did not remove the + hang.
• Endpoint security, firewall, registry, ACL, or Windows policy: no weakening or diagnostic bypass was performed. The ultimate OS/security component responsible for the size-dependent spawn latency therefore remains unknown.

The Desktop update also triggered a new Windows network-access prompt. It was accepted, and inbound firewall state differed from the older package version. Because the app update and permission prompt occurred before the first post-update control test, they were treated as a confounder rather than claimed as a cause or fix.

---

7. Related Runtime Observations

Computer Use remained functionally usable after warm-up, but additional latency was observed after the complete runtime rebuild:

• list_apps: approximately 545 ms.
• Initial Calculator targeting required an unsuccessful ~6.1 s poll plus a 2 s recovery wait.
• A valid accessibility element click followed by the required combined verification state eventually succeeded, but the click-plus-verification call took approximately 69.4 seconds.

These observations are not presented as direct proof of the + root cause. They show that severe helper latency can persist after the UI has warmed and after clean runtime reconstruction.

The Open in... target-menu symptom similarly has a cold/warm signature. Its approximately 60-second cold delay is measured and reproducible, but no dedicated Procmon trace has yet established that it launches the identical PowerShell payload. It is therefore reported as a likely related secondary symptom, not as proven identical causation.

---

8. Evidence Classification

Proven on this system

• The main Chromium thread blocks synchronously in uv_spawn / CreateProcessW during the captured + freeze.
• The correlated child is PowerShell running the packaged Windows desktop-app metadata lookup through a multi-kilobyte -EncodedCommand payload.
• The PowerShell child shows a long pre-execution/process-initialization stall.
• PowerShell launch latency scales sharply with command-line size in isolated harmless controls.
• The exact same application script body completes in 2.008 seconds when supplied through stdin.
• Disabling the complete Computer Use plugin removes the observed cold + delay in the controlled checks.
• Clean Computer Use and full shared-runtime rebuilds do not remove the freeze when Computer Use is enabled.
• Cold Open in... application-target discovery takes approximately 60 seconds and is then cached for an immediate warm repetition.

Strongly indicated

• The large encoded PowerShell command-line launch is the immediate blocking mechanism behind the + freeze.
• The Open in... delay likely involves a related cached application-discovery path.

Not yet proven

• Which Windows, security, or endpoint-protection component makes large PowerShell process creation scale so poorly on this machine.
• That the Open in... menu launches the exact same child command line.
• That Computer Use alone is the ultimate underlying cause; it is the feature path that reliably activates the affected discovery behavior.

---

9. Proposed Remediation

1. Never run discovery on the Chromium UI thread

Execute desktop-application discovery in a worker/background process. A slow uv_spawn, security scan, or process initialization must not block menu rendering or window events.

1. Avoid multi-kilobyte encoded command lines

Pass the script through stdin using powershell.exe -Command -, or write a controlled temporary .ps1 file and invoke it with -File. The stdin route eliminated the measured pre-script stall without changing the script body.

1. Render immediately and refresh asynchronously

Open the + and Open in... menus immediately with cached or partial results, then refresh discovered application targets in the background.

1. Add timeout, cancellation, and process cleanup

Bound helper startup and execution separately. Cancel stale discovery when the menu closes or the user starts another action, and ensure abandoned children are terminated cleanly.

1. Instrument process-launch phases

Log timestamps for request start, uv_spawn entry/return, child creation, first-script marker, first output, completion, cancellation, and cache hit/miss. This will distinguish process creation, endpoint scanning, PowerShell initialization, and script runtime in support traces.

1. Deduplicate concurrent discovery requests

If Computer Use initialization and file-target discovery request the same metadata, share one in-flight/background lookup instead of synchronously spawning multiple helpers.

---

10. Sanitized Evidence Available

The following artifacts are preserved locally and can be supplied in a sanitized form if an OpenAI engineer requests them:

• Procmon CSV and derived process timeline for the manual + reproduction.
• Sanitized Procmon analysis and process-tree summary.
• Sanitized partial decoded PowerShell metadata script.
• Sanitized packaged-code snippet linking the child to the desktop metadata lookup.
• Command-line-size and stdin benchmark outputs.
• Clean reinstall and runtime-rebuild manifests, hashes, and health-check summaries.
• Screenshot of Open in... stalled on Loading available apps....

For privacy and security, raw UserAssist contents, full memory dumps, authentication material, browser-profile data, and unfiltered user paths will not be uploaded publicly. A narrower sanitized artifact can be prepared if maintainers identify the exact evidence they need.

---

11. GitHub Actions Potential-Duplicate Review

GitHub Actions suggested #34572 as a potential duplicate. That report was reviewed, together with the two issues suggested from its own duplicate chain:

| Issue | Overlap | Material difference from this report |
|---|---|---|
| #34572 | Windows Codex becomes temporarily unresponsive around a newly opened chat and recovers warm | Freeze begins after characters are typed, lasts 3–10 seconds, and has no reported Computer Use A/B, PowerShell child, command-line scaling result, or uv_spawn stack |
| #34450 | Windows UI/input latency | Describes per-keystroke lag and long-history session freezes/crashes rather than cold desktop-app discovery |
| #34327 | Windows main-process freezes with low CPU | Correlates the freezes with Codex Micro HID/serial native modules and a device-module stub; this report correlates a different cold path with PowerShell desktop metadata discovery and Computer Use |

These reports may belong to a broader class of synchronous Windows main-process discovery work, but the currently available evidence does not establish that any of them is an exact duplicate of this issue. This issue should therefore remain open unless maintainers confirm that the underlying implementation path is shared.