codex_work_ui_latency
What version of the Codex App are you using (From “About Codex” dialog)?
26.805.11740
What subscription do you have?
UI Delay when no task running
What platform is your computer?
Win11 26200.8875；AMD Ryzen 7 5800H with Radeon Graphics (3.20 GHz)；16.0 GB
What issue are you seeing?
<html>
<body>
<!--StartFragment--><html><head></head><body><p><span>Adding another Windows 11 WPR data point. This reproduces even when no Codex turn or user task is active.</span></p><h3><span>Environment</span></h3><ul><li><p><span>Unified ChatGPT/Codex Windows desktop app</span></p></li><li><p><span>Package observed in the traces: </span><code><span>OpenAI.Codex 26.730.8199.0</span></code></p></li><li><p><span>Windows 11 build </span><code><span>26200</span></code></p></li><li><p><span>16 logical processors</span></p></li><li><p><span>Microsoft Pinyin was active during both latest reproductions</span></p></li><li><p><span>Sogou IME had already been uninstalled</span></p></li><li><p><span>In-app feedback Session ID: </span><code><span>019fcd47-a15d-7df2-bc76-3571fe09c46c</span></code></p></li></ul><h3><span>User-visible behavior</span></h3><ul><li><p><span>Typing intermittently freezes for approximately 2–3 seconds.</span></p></li><li><p><span>Keystrokes are accepted but characters appear later in a batch.</span></p></li><li><p><span>The stutter is not limited to Codex; unrelated applications such as WeChat can become similarly laggy while the desktop app is open.</span></p></li><li><p><span>Audio remains normal.</span></p></li><li><p><span>This occurs while Codex shows no active task or turn.</span></p></li></ul><p><span>This is very similar to the buffered first-input behavior reported in #29543, but in this case the problem can recur during an existing conversation and affect other Windows applications.</span></p><h3><span>WPR evidence</span></h3><p><span>Two independent WPR traces reproduced the issue with Microsoft Pinyin. Both traces were complete with no lost events.</span></p><p><span>For the ChatGPT foreground UI thread, exact 200 ms windows showed:</span></p>
Trace | Running | Ready | Waiting
-- | -- | -- | --
1 | 54.653 ms | 2.806 ms | 142.541 ms
2 | 80.875 ms | 3.199 ms | 115.926 ms
<p><span>The very low Ready time does not support CPU scheduler starvation. UI-thread CPU stacks repeatedly entered </span><code><span>chrome.dll</span></code><span> / </span><code><span>ChatGPT.exe</span></code><span>, with substantial Windows filesystem paths through </span><code><span>FLTMGR</span></code><span> and </span><code><span>NTFS</span></code><span>.</span></p><p><span>The bundled </span><code><span>codex.exe app-server --analytics-default-enabled</span></code><span> remained active despite there being no user task:</span></p><ul><li><p><span>Five-second sampled CPU weight: approximately </span><code><span>5,427.877 ms</span></code><span> and </span><code><span>6,582.230 ms</span></code><span> in the two traces.</span></p></li><li><p><span>In the second marked 200 ms interval, the app-server had approximately 991 CPU samples:</span></p><ul><li><p><span>628 included </span><code><span>FLTMGR</span></code></p></li><li><p><span>259 included </span><code><span>NTFS</span></code></p></li></ul></li><li><p><span>The same interval contained 174 I/O operations totaling 1,175,552 bytes, mainly targeting </span><code><span>%USERPROFILE%\.codex\logs_2.sqlite*</span></code><span>.</span></p></li></ul><p><span>A separate read-only check found:</span></p><ul><li><p><code><span>logs_2.sqlite</span></code><span>: 844,763,136 bytes, approximately 805.6 MiB</span></p></li><li><p><code><span>logs_2.sqlite-wal</span></code><span>: approximately 5.26 MiB and still updating</span></p></li></ul><p><span>No database files were modified or cleared.</span></p><h3><span>Current interpretation</span></h3><p><strong><span>Confirmed:</span></strong><span> the immediate latency is occurring on the desktop UI thread in Chromium/ChatGPT and filesystem-related paths, rather than because the UI thread is waiting in the CPU Ready queue.</span></p><p><strong><span>Highly likely:</span></strong><span> periodic app-server logging/database or filesystem-metadata work is an internal trigger or amplifier even while no user task is running.</span></p><p><strong><span>Not yet proven:</span></strong><span> the large log database is the sole root cause. Other reports indicate that similar Windows input lag can still reproduce with a small or freshly recreated log database.</span></p><p><span>DPC/ISR activity, hard faults, total CPU saturation, and a specific third-party IME have been substantially reduced as explanations. The captured GPU/DWM frame tables were not exportable, so final application-versus-DWM frame attribution remains unavailable.</span></p><p><span>Could the maintainers confirm whether this belongs to the same Windows desktop performance regression as this issue and #29543? Sanitized WPA exports and the original WPR ETLs can be provided privately if needed.</span></p></body></html><!--EndFragment-->
</body>
</html>
What steps can reproduce the bug?
<html>
<body>
<!--StartFragment--><html><head></head><body><p><span>Adding another Windows 11 WPR data point. This reproduces even when no Codex turn or user task is active.</span></p><h3><span>Environment</span></h3><ul><li><p><span>Unified ChatGPT/Codex Windows desktop app</span></p></li><li><p><span>Package observed in the traces: </span><code><span>OpenAI.Codex 26.730.8199.0</span></code></p></li><li><p><span>Windows 11 build </span><code><span>26200</span></code></p></li><li><p><span>16 logical processors</span></p></li><li><p><span>Microsoft Pinyin was active during both latest reproductions</span></p></li><li><p><span>Sogou IME had already been uninstalled</span></p></li><li><p><span>In-app feedback Session ID: </span><code><span>019fcd47-a15d-7df2-bc76-3571fe09c46c</span></code></p></li></ul><h3><span>User-visible behavior</span></h3><ul><li><p><span>Typing intermittently freezes for approximately 2–3 seconds.</span></p></li><li><p><span>Keystrokes are accepted but characters appear later in a batch.</span></p></li><li><p><span>The stutter is not limited to Codex; unrelated applications such as WeChat can become similarly laggy while the desktop app is open.</span></p></li><li><p><span>Audio remains normal.</span></p></li><li><p><span>This occurs while Codex shows no active task or turn.</span></p></li></ul><p><span>This is very similar to the buffered first-input behavior reported in #29543, but in this case the problem can recur during an existing conversation and affect other Windows applications.</span></p><h3><span>WPR evidence</span></h3><p><span>Two independent WPR traces reproduced the issue with Microsoft Pinyin. Both traces were complete with no lost events.</span></p><p><span>For the ChatGPT foreground UI thread, exact 200 ms windows showed:</span></p>
Trace | Running | Ready | Waiting
-- | -- | -- | --
1 | 54.653 ms | 2.806 ms | 142.541 ms
2 | 80.875 ms | 3.199 ms | 115.926 ms
<p><span>The very low Ready time does not support CPU scheduler starvation. UI-thread CPU stacks repeatedly entered </span><code><span>chrome.dll</span></code><span> / </span><code><span>ChatGPT.exe</span></code><span>, with substantial Windows filesystem paths through </span><code><span>FLTMGR</span></code><span> and </span><code><span>NTFS</span></code><span>.</span></p><p><span>The bundled </span><code><span>codex.exe app-server --analytics-default-enabled</span></code><span> remained active despite there being no user task:</span></p><ul><li><p><span>Five-second sampled CPU weight: approximately </span><code><span>5,427.877 ms</span></code><span> and </span><code><span>6,582.230 ms</span></code><span> in the two traces.</span></p></li><li><p><span>In the second marked 200 ms interval, the app-server had approximately 991 CPU samples:</span></p><ul><li><p><span>628 included </span><code><span>FLTMGR</span></code></p></li><li><p><span>259 included </span><code><span>NTFS</span></code></p></li></ul></li><li><p><span>The same interval contained 174 I/O operations totaling 1,175,552 bytes, mainly targeting </span><code><span>%USERPROFILE%\.codex\logs_2.sqlite*</span></code><span>.</span></p></li></ul><p><span>A separate read-only check found:</span></p><ul><li><p><code><span>logs_2.sqlite</span></code><span>: 844,763,136 bytes, approximately 805.6 MiB</span></p></li><li><p><code><span>logs_2.sqlite-wal</span></code><span>: approximately 5.26 MiB and still updating</span></p></li></ul><p><span>No database files were modified or cleared.</span></p><h3><span>Current interpretation</span></h3><p><strong><span>Confirmed:</span></strong><span> the immediate latency is occurring on the desktop UI thread in Chromium/ChatGPT and filesystem-related paths, rather than because the UI thread is waiting in the CPU Ready queue.</span></p><p><strong><span>Highly likely:</span></strong><span> periodic app-server logging/database or filesystem-metadata work is an internal trigger or amplifier even while no user task is running.</span></p><p><strong><span>Not yet proven:</span></strong><span> the large log database is the sole root cause. Other reports indicate that similar Windows input lag can still reproduce with a small or freshly recreated log database.</span></p><p><span>DPC/ISR activity, hard faults, total CPU saturation, and a specific third-party IME have been substantially reduced as explanations. The captured GPU/DWM frame tables were not exportable, so final application-versus-DWM frame attribution remains unavailable.</span></p><p><span>Could the maintainers confirm whether this belongs to the same Windows desktop performance regression as this issue and #29543? Sanitized WPA exports and the original WPR ETLs can be provided privately if needed.</span></p></body></html><!--EndFragment-->
</body>
</html>
What is the expected behavior?
_No response_
Additional information
_No response_
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action