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

[Liu8976]

Description

On the Codex Windows desktop app, typing in a newly created conversation consistently freezes after the first few characters.

Example: when rapidly typing hkjshkjhdjkhskja, the UI initially displays only hkj. The caret continues blinking, but subsequent characters do not appear. After approximately 2–3 seconds, all buffered characters appear at once.

This occurs with both English and Chinese input. After the initial freeze, typing returns to normal.

Reproduction steps

1. Open Codex desktop on Windows.
2. Click New conversation.
3. Immediately type a sequence of characters quickly.
4. Observe that only the first few characters appear.
5. Wait 2–3 seconds; the remaining buffered characters then appear together.

The issue reproduces in every new conversation.

Expected behavior

Characters should appear immediately and continuously while typing.

Troubleshooting already performed

The issue persists after:

• Rebooting Windows and clearing stale Codex/Node processes.
• Testing in a completely new conversation.
• Testing both English and Chinese input methods.
• Disabling Ambient Suggestions.
• Disabling all plugins and node_repl.
• Starting Codex with --disable-gpu.
• Starting Codex with --disable-spell-checking.
• Starting Codex with a completely fresh --user-data-dir.
• Confirming that CPU, memory, page file, IME processes, and GPU usage are normal.

This strongly suggests a synchronous first-input/editor initialization task blocking the renderer main thread.

Environment

• Codex desktop package: 26.616.6631.0
• Embedded Chromium/product version: 149.0.7827.115
• OS: Windows 11 Pro, 64-bit
• Windows build: 26200
• GPU: NVIDIA GeForce GTX 1050 Ti
• GPU driver: 32.0.15.7700
• Display: 1920×1080 at 60 Hz

[github-actions]

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

• Codex Desktop Windows 26.611.61753: chat switching and composer typing feel laggy #28735

Powered by Codex Action

[till-tus]

I’m seeing the same first-typing freeze described here, but also similar brief stutters on Codex launch, opening a new chat, and opening Settings.

I opened #29821 with diagnostics from a 30s Windows capture. In my case the stutters correlate with Codex main/renderer/app-server CPU and memory spikes, while GPU, disk, WMI, and total system CPU stay modest. It may be the same underlying renderer/startup initialization issue, just visible in more places.

[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.

[jianzhangg]

I can reproduce what looks like the same first-input freeze on Windows Codex Desktop, with a more specific IME trigger.

Environment:

• Codex desktop package: OpenAI.Codex 26.623.5546.0
• OS: Windows 25H2, build 26200.8655 (Windows Home China)
• Input method: WeChat Input Method / 微信输入法 2.1.0.31
• Language: Chinese Pinyin input

Behavior:

• This happens in every newly opened Codex conversation.
• Waiting several seconds before typing does not avoid the freeze.
• The app does not freeze immediately when the new conversation opens.
• The freeze happens specifically when I type Pinyin for the first Chinese character and press Space to select/commit the first IME candidate into the Codex composer.
• The first committed Chinese character takes several seconds to appear / the input UI stalls for several seconds.
• After that first IME commit, subsequent Chinese input in the same conversation works normally.
• I have not observed the same WeChat IME behavior in Edge or other apps.

This makes it feel like the Codex composer has an expensive first committed-text / IME composition path in a newly created conversation, rather than a general system-wide IME slowdown.

[zopenb]

I can reproduce this consistently on a newer Windows build, and an external
100 ms sampler plus local bundle tracing narrowed the trigger considerably.
This also appears related to #27924, although in this reproduction digits,
English, and Chinese all trigger the same stall.

Environment

• Microsoft Store package: OpenAI.Codex 26.707.3748.0
• Electron: 42.1.0
• Chromium: 150.0.7871.101
• OS: Windows 10 19045, x64
• Input method: Microsoft Pinyin (also reproduces with plain digits/English)
• CPU/RAM: Intel i7-8750H, 32 GB

High-resolution capture

Two consecutive new-task reproductions produced external-sampler gaps of:

• 4.620 s
• 4.616 s

During both gaps:

• The Electron main ChatGPT.exe process jumped from roughly 265-645 MB
  private memory to 1.43-1.46 GB, then dropped immediately after the stall.
• The renderer stayed around 405 MB.
• The Codex app-server stayed around 100 MB.
• IME processes remained normal.
• Windows continued to report the process as Responding=True, so no standard
  Application Hang event was emitted.

This did not change after disabling all plugins/MCP servers, disabling GPU,
testing a fresh task, or changing app-server process priority.

Trigger path

In the desktop bundle, the new-task composer subscribes to
composerController.hasText(). The local-conversation prewarm effect is gated
on that value and schedules work after 300 ms. That path reaches
prewarm-conversation-for-host and then thread/start.

Locally observed thread/start durations were approximately 4.3-8.2 s.
The main-process response path parses the app-server response and forwards the
full response through webContents.send(). The transient main-process memory
growth suggests that parsing/serialization or Electron structured cloning of
that response is worth instrumenting, although I cannot prove from the bundle
alone which stage owns the allocation.

Local timing experiment

As a diagnostic experiment only, I changed the effect gate from the equivalent
of:

if (hasText) {

to:

if (hasText || isEligibleLocalWorkspace) {

The first-input freeze disappeared in repeated tests on this machine. This is
not proposed as a production fix: the inner prewarm function still rejects an
empty persisted prompt, and eager prewarming needs cancellation/reuse behavior
for abandoned tasks. It does, however, strongly correlate the user-visible
stall with the first-text-triggered local prewarm path rather than IME, GPU, or
plugin initialization.

Suggested areas to instrument

• Duration and payload size for thread/start responses.
• JSON parsing and webContents.send() structured-clone time in the Electron
  main process.
• Main-process private-memory delta during response routing.
• A Windows regression metric for first-keystroke/composer latency.
• Whether the response can be slimmed, streamed, lazily hydrated, or routed
  without cloning the full object on the main thread.

I can recapture a sanitized sampler trace if a maintainer specifies the most
useful counters or logging fields.

[quentinleon]

Also seeing this behavior consistently. Got a performance trace of it:
no-active-thread-019f5a8c-98f3-7370-b0f5-721b6d79699b