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

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

• #28735

Powered by Codex Action

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.

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: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

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.

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.

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.

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

Additional Windows reproduction: Proxmox VM, current build, 5-6s thread/start calls and occasional 30s stalls

I can reproduce the same first-input freeze described in this issue on a newer Windows Codex build. My environment is a Windows guest running on a Proxmox server, which also helps show how storage latency can amplify the underlying first-input problem.

Environment

• Codex desktop package: OpenAI.Codex 26.707.12708.0
• Codex app-server: 0.144.5
• Embedded Chromium/product version: 150.0.7871.115
• Guest OS: Windows Server 2025 Standard, build 26100
• Hypervisor: Proxmox/QEMU
• Guest hardware: 8 vCPU, 15.8 GB RAM
• System disk presented to Windows as a QEMU virtual SATA HDD

User-visible behavior

• The problem occurs most often on the first keystrokes in a newly opened conversation.
• Typed characters stop appearing and clicks stop responding.
• The app may turn white and Windows labels it unresponsive.
• After several seconds--and sometimes roughly 20-30 seconds--the buffered input appears and the app resumes normally.
• CPU and memory are not exhausted during the stall.

Windows Error Reporting has recorded AppHangTransient events for the Codex/ChatGPT process on July 12, July 14, and July 16. The current Codex process tree was using approximately 1.6 GB working set while the guest still had about 9.7 GB of available RAM, so this does not look like memory pressure or paging exhaustion.

Codex log timings

The current build repeatedly logged slow successful thread/start responses:

method=thread/start durationMs=5243
method=thread/start durationMs=5556
method=thread/start durationMs=5143
method=thread/start durationMs=5149
method=thread/start durationMs=1732

The app-server initialization handshake for the current launch also took 5983 ms.

On the preceding installed package, 26.707.9981.0, the desktop log captured an exact 30-second app-server initialization timeout:

initialize_handshake_result durationMs=30004 outcome=failure
errorMessage="Codex app-server initialize handshake timed out"

The 5-6 second thread/start durations closely match the trigger path and timings reported in the detailed investigation above. The 30-second handshake failure may explain some of the longer episodes, although I cannot prove that every 20-30 second UI stall is the same timeout.

Storage and SQLite observations

Task Manager showed repeated 100% disk-active-time bursts with only a few MB/s of throughput. A separate 15-second read-only counter sample averaged roughly 57% disk activity while transferring only about 0.5 MB/s. The virtual disk reports healthy and has ample free space, so this looks like latency rather than capacity exhaustion.

I also checked the local Codex SQLite files without modifying, vacuuming, checkpointing, or deleting anything:

• state_5.sqlite is only 1.69 MB and PRAGMA quick_check returned ok.
• The state database has the expected thread indexes and no meaningful free-page buildup.
• Recent desktop logs contained no SQLITE_BUSY, database is locked, or corruption errors.
• logs_2.sqlite is approximately 437 MB, with a 6.3 MB WAL.
• About 75% of the main logging database pages are currently on SQLite's freelist, indicating substantial retained file size after log churn.
• A read-only full-table aggregate against logs_2.sqlite took roughly 26 seconds on this guest storage.

This does not prove that the first-input path performs a full scan of logs_2.sqlite. In fact, the state and logging databases have relevant indexes, and #28855 reports that Windows lag can reproduce even after the log database is recreated and remains small. My interpretation is therefore:

1. The first-text-triggered local conversation prewarm / thread/start path is the primary issue.
2. Slow virtual-disk latency and a large, heavily churned logging database can amplify the duration on some systems.
3. The evidence does not point to corruption in state_5.sqlite.

Suggested instrumentation

It would be useful to capture, separately:

• time from the first non-empty composer state to the prewarm request;
• app-server thread/start execution time;
• response payload size;
• JSON parsing and Electron webContents.send() / structured-clone time;
• main-thread blocking time and transient private-memory growth;
• file I/O attributable to state_5.sqlite, logs_2.sqlite, and rollout hydration during this path.

The most important product behavior would be to keep the composer responsive while local conversation prewarming and thread creation complete, even when the app-server or storage layer is slow.