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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Jun 23, 2026
2. github-actions commented on Jun 23, 2026

   

   github-actionsBot

   on Jun 23, 2026 – with GitHub Actions

   Contributor

   More 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
3. till-tus commented on Jun 24, 2026

   

   till-tus

   on Jun 24, 2026 – with ChatGPT Codex Connector

   More actions

   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.
4. Yassycodes commented on Jun 25, 2026

   

   Yassycodes

   on Jun 25, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👍React with 👍1Reacted by Frulfump
5. jianzhangg commented on Jun 28, 2026

   

   jianzhangg

   on Jun 28, 2026

   More actions

   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.
6. zopenb commented on Jul 11, 2026

   

   zopenb

   on Jul 11, 2026

   More actions

   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.
7. quentinleon commented on Jul 13, 2026

   

   quentinleon

   on Jul 13, 2026

   More actions

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

   👍React with 👍2Reacted by Frulfump and painbaker
8. jimerb commented on Jul 16, 2026

   

   jimerb

   on Jul 16, 2026

   More actions

   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.
9. Kiyan1929 commented on Jul 23, 2026

   

   Kiyan1929

   on Jul 23, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming the same behavior on a newer Windows desktop build.

   Environment

   • OpenAI Codex/ChatGPT desktop package: 26.715.10079.0 (x64)
   • Embedded Chromium/Electron annotation: 150.0.7871.124
   • Windows 11 Pro x64, build 26200
   • NVIDIA RTX 3090, driver 32.0.16.1074
   • 32 GB RAM (roughly 16 GB free during testing)

   Additional reproduction evidence

   • The same 2–3 second buffered-input freeze occurs in ChatGPT mode, not only Codex mode.
   • Both numeric input (123456789) and alphabetic input (abcabcabc) are affected.
   • The stall is not limited to the first input in a new chat; it can also happen suddenly in the middle of typing.
   • Notepad remains responsive on the same machine.
   • A newly opened Codex chat temporarily felt improved after closing/reopening the window, but process inspection showed the original Electron main/renderer processes were still alive, so this was not a true full-app restart or clean cache A/B test. Intermittent stalls remained.
   • No matching Windows Application Hang or Application Error event was recorded during inspection.
   • The desktop browser profile recorded the previous exit_type as "Crashed".
   • Desktop logs contained task/renderer state synchronization errors including Received turn/started for unknown conversation and Received turn/completed for unknown conversation.

   This appears to be a shared Windows desktop composer/renderer issue rather than a Codex-only conversation or project-scanning issue. I am adding this evidence here instead of opening a duplicate.
10. wangzhuo0601 commented on Aug 3, 2026

    

    wangzhuo0601

    on Aug 3, 2026

    More actions

    Still reproducible on OpenAI.Codex 26.727.6591.0, Windows x64.

    After opening each new conversation, only the first few typed characters are displayed. The remaining buffered characters appear together later.This affects both English and Chinese input.

    The issue persists even after fully restarting both Codex and Windows.

    Clicking the sidebar or switching conversations also results in similar UI freezes.

    👍React with 👍1Reacted by jimerb
11. etraut-openai

    marked Codex App freezes for 2-3 seconds when typing the first character in a new session #30449 as a duplicate of this issue on Aug 6, 2026