Windows Desktop UI stutters on launch, new chat, first typing, and Settings

[till-tus]

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

Version 26.616.81150 • Released 23 Jun 2026

Observed installed package:

OpenAI.Codex 26.616.10790.0
App server version in logs: 0.142.0

What subscription do you have?

5x Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64
Windows 11 Pro, build 26200
CPU: AMD Ryzen 5 5600X, 6 cores / 12 logical processors
GPU: AMD Radeon RX 7600
GPU driver: 32.0.31021.1015
Power plan: High performance

What issue are you seeing?

Codex Desktop repeatedly causes brief UI/cursor/input stutters during first-use interactions:

• On opening Codex, the cursor/UI stutters briefly, then becomes smooth.
• On opening a new chat, the same stutter happens, then becomes smooth.
• In a new chat, the first typed characters appear, then the UI freezes briefly, then typing is smooth.
• Opening Settings also causes a brief stutter, then becomes smooth.

This reproduces after a fresh reinstall and after deleting Codex data.

Local diagnostics suggest the stutter correlates with Codex Desktop process CPU and memory spikes, not disk, GPU, WMI, Defender, or WSL:

30 second diagnostic capture while reproducing:

Main Codex.exe process:
  CPU used: ~18.4 CPU seconds
  Peak working set: ~1.1 GB
  Peak private memory: ~1.9 GB

Codex app-server process:
  CPU used: ~5.05 CPU seconds

Renderer process:
  CPU used: ~4.61 CPU seconds

Counters:
  Codex process CPU peaked around 147.7% processor time
  Total system CPU peaked around 40.18%
  Physical disk time peaked around 5.23%
  WMI Provider Host CPU stayed low, max around 4.67%
  Codex GPU process GPU utilization stayed below 1%

Sanitized relevant Codex Desktop log excerpts:

initialize_handshake_result durationMs=69 outcome=success
window main frame finished load startupElapsedMs=95
window ready-to-show startupElapsedMs=111

[startup][renderer] app routes mounted after 4058ms

method=mcpServerStatus/list durationMs=1914
method=mcpServerStatus/list durationMs=1468

[git] [git-origins] worker-complete dirCount=6 elapsedMs=635
[git-repo-watcher] Starting git repo watcher

error [wsl] error retrieving eligible distro error="Error: Command failed: wsl.exe --status ..."

Note: WSL_DISTRO_NAME is unset in Process/User/Machine env. WSL is not installed, but wsl.exe --status completes locally in about 34ms, so this does not appear to explain the full stutter by itself.

What steps can reproduce the bug?

1. Start Codex Desktop on Windows.
2. Observe brief cursor/UI stutter after launch, followed by smooth behavior.
3. Open a new chat.
4. Observe another brief stutter, followed by smooth behavior.
5. Type a few characters in the new chat.
6. The first characters appear, then the UI briefly freezes/stutters, then typing is smooth.
7. Open Settings.
8. Observe another brief stutter, followed by smooth behavior.

This reproduces consistently on this machine and also reproduced immediately after a fresh reinstall with Codex data removed.

What is the expected behavior?

Codex Desktop should remain responsive during launch, new chat creation, first typing in a new chat, and opening Settings. Startup/background initialization should not block mouse/cursor movement or text input.

Additional information

Local mitigations tried without improvement:

• Fresh reinstall and deleting Codex data.
• Verified WSL_DISTRO_NAME is not set.
• Temporarily disabled plugins/MCP/notify via diagnostic minimal config.
• Temporarily disabled sidebar PR icons and removed a broad trusted home-directory project.
• Temporarily disabled/cleared desktop global state for global dictation hotkey, mobile connected state, Chrome extension sync management, saved workspace roots, project order, active workspace roots, and avatar overlay.
• Rotating session/log files was considered but is unlikely to be root cause because the issue reproduced immediately after fresh install.

Diagnostics were collected with a local PowerShell sampler that recorded process CPU/memory, Windows counters, GPU counters, WMI activity, and Codex Desktop logs. I can provide a further-sanitized subset if helpful, but I am not attaching raw logs because they may contain local paths, thread IDs, and prompt history.

[github-actions]

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

• Codex Windows desktop freezes for 2–3 seconds during first typing in every new conversation #29543

Powered by Codex Action

[leanderriefel]

This has been going on for me for more than a week already and makes the app almost unusable for me as I work with a lot of threads side by side. I hope this gets a high priority and fix soon!

[Yassycodes]

This has been happening to me since June 12th, and I reported the bug a week ago. Still nothing yet, but I need something soon, as this is not usable for me in the app anymore.

[Yassycodes]

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: #29949 (comment)

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

[till-tus]

Update: after a complete reinstall of Windows and a fresh Codex installation, I can no longer reproduce the stuttering described in this issue.

This was a full machine reinstall, not merely reinstalling Codex or deleting its application data. This means, I cannot confirm whether the issue was resolved by a Codex update or whether something in my previous Windows environment was contributing to it. Although I have to add that the latest version of the ChatGPT app (formerly codex) was not performing any better under the previous environment. No new release in between that update and the fresh windows install.

Since other users have reported similar behavior, I’ll leave the issue open for now, but my own system is currently unaffected.

[natnopa-stack]

Copy-ready comment for #29821

I can add a newer single-host Windows observation that separates startup/catalog work
from long-thread history hydration.

Environment for this run:

• Codex Desktop 26.727.6591.0 (Microsoft Store/MSIX)
• Codex CLI/app-server 0.145.0
• Windows x64
• only redacted aggregate metrics are reported

The largest observed endpoint durations in the affected run were approximately:

• app/list: 40.1 s
• mcpServerStatus/list: 32.9 s
• plugin/list: 15.6 s
• skills/list: 8.4 s

These calls can overlap, so the values must not be summed into one startup duration.
The logs also report queue wait separately from endpoint execution time.

One narrow causal finding was reproducible on this build: persisted state said the Pet
was tucked away, but a hidden 408 x 400 overlay window remained and continued issuing
skills/list requests at roughly ten-second intervals. After sending one standard
WM_CLOSE to the uniquely identified hidden overlay (no process termination,
injection, elevation, or Codex-file write):

• the visible primary window remained;
• no new overlay-origin skills/list request appeared in the immediate 25-second
  verification window;
• an extended read-only check about 17 minutes later still showed no newer overlay
  polling.

This only proves that the tucked-away overlay caused that recurring catalog polling on
this build. It does not explain or eliminate the first app/list or MCP status cost.

Suggested client changes:

1. When persisted state says the Pet is closed, do not create or prewarm its renderer;
   cancel renderer-owned timers and queries when it becomes hidden.
2. Coalesce identical in-flight skills/list, plugin/list, app/list, and
   mcpServerStatus/list requests across windows.
3. Use mcpServerStatus/list with detail: "toolsAndAuthOnly" for composer/status
   surfaces; request the full resource view only when MCP settings are opened.
4. Render the last successful app/plugin catalogs immediately and refresh them after
   the composer is interactive. Preserve the previous snapshot when refresh fails.
5. Measure endpoint execution time, queue wait, caller window/renderer, and time to
   first responsive composer input as separate values.

Suggested acceptance criteria:

• the primary composer accepts input before remote catalog refresh completes;
• a tucked-away Pet produces zero overlay-origin catalog requests for two idle minutes;
• N simultaneous identical callers produce one app-server request;
• opening MCP settings still fetches and displays the complete resource surface;
• Pet wake/tuck, app authorization, plugin installation, and skill-change detection
  continue to work.

The long-task hydration issue appears to be a separate path and is tracked more
directly in #29590.