Windows Codex app causes mouse stutter during startup and task switching without CPU/Disk saturation

Summary

On Windows 11, launching the Codex desktop app and switching/opening tasks causes visible system mouse stutter. The issue persists after a clean Windows 11 reinstall and after multiple local mitigations. It is severe enough to affect normal PC operation during Codex startup.

Environment

OS: Windows 11, clean reinstall
Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Codex version: 26.707.9981.0
WebView2 Runtime: 150.0.4078.65
GPU: NVIDIA GeForce RTX 4060 Ti
NVIDIA driver: 32.0.16.1074, driver date 2026-07-02
Mouse: wired HID mouse, SteelSeries device HID\VID_1038&PID_1361&MI_00&COL01

Symptoms

Mouse stutters during Codex startup, originally for roughly 30 seconds.
Mouse also stutters when opening/switching Codex tasks, especially tasks that have not been opened recently.
The behavior occurs only after starting Codex/projects; normal system use before opening Codex does not show the same stutter.
Reinstalling Windows 11 did not resolve the issue.

Reproduction

Close Codex completely.
Start Codex desktop app.
Observe mouse movement during startup and while the task list/task UI loads.
Open or switch to a Codex task.
Observe additional mouse stutter.

Diagnostics already performed

The following tests did not resolve the issue:

Clean Windows 11 reinstall.
Closing ToDesk.
Closing QQ Music and SteelSeries background apps.
Moving the wired mouse to another rear USB port.
Lowering SteelSeries mouse polling rate from 800Hz to 125Hz.
Disabling Todesk Virtual Display Adapter and retesting, then re-enabling it.
Windows app Repair for Codex.
GPU preference changes: power saving vs high performance.
Disabling Windows windowed game optimizations.
Launching with GPU rendering disabled.
Deleting WebView/Chromium shader caches (GrShaderCache, ShaderCache, GPUPersistentCache).

Local profile/cache observations

Moving the Codex WebView profile temporarily improved the issue, but the stutter returned after Codex regenerated the local profile/cache.

Observed profile sizes:

New profile shortly after reset: ~65 MB
New profile after Codex startup/use: ~121 MB
Old profile backup: ~131 MB

The growth was mainly in Chromium/WebView component/cache directories such as:

component_crx_cache
WasmTtsEngine
WidevineCdm
Default
GrShaderCache

This suggests clearing local profile/cache is only a temporary mitigation.

WPR/WPA/xperf evidence

A Windows Performance Recorder trace was captured during a reproduced stutter:

Trace duration: 169 seconds
Events: ~27.5 million
Lost events: 0
ETL size: ~2.72 GB

The trace is available if maintainers want it, but I am not attaching it publicly because ETL traces can include local paths/process metadata.

High-level analysis with WPA/xperf:

No sustained CPU, disk, or memory saturation.
During the 70s-100s peak window, the system still had ~75% Idle CPU.
During the 120s-125s UI-delay window, the system still had ~78% Idle CPU.
Main contributors in the peak windows included ChatGPT.exe, codex.exe, dwm.exe, and WebView-related activity, but none saturated the system.
uidelay captured a foreground ChatGPT.exe message-check delay of 218 ms on Chrome_RenderWidgetHostHWND / Chrome_WidgetWin_1.
DPC/ISR activity showed USB/NVIDIA/DirectX-related modules active, but no single driver-level stall clearly explains a 30-second user-visible stutter.

Codex logs

Codex desktop logs during startup/task use showed repeated frontend/UI related messages, including many occurrences of:

ResizeObserver loop completed with undelivered notifications.

Startup logs also showed relatively slow initialization calls in some runs, for example:

plugin/list durationMs=1898
plugin/list durationMs=4393

There were also repeated browser/sidebar lifecycle warnings around task/window ownership, but no clear system-level crash or display driver reset was found in Windows Event Viewer.

Expected behavior

Starting Codex and switching tasks should not cause system-level mouse stutter when CPU, disk, and memory are not saturated.

Actual behavior

Codex startup/task switching causes visible mouse stutter even on a clean Windows 11 install, and the issue returns after local profile/cache regeneration.

Notes

This appears more consistent with Codex desktop frontend/WebView rendering or initialization behavior than with a general Windows, USB port, mouse polling rate, GPU preference, or old local profile issue.

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

Massive lag and stuttering on new Windows ChatGPT app #32178
Windows app repeatedly freezes on launch while synchronously hashing bundled executables on the main thread #32076

Powered by Codex Action

This is an additional reproduction of the issue on Windows 10 with a newer Codex Desktop build. It appears closely related to #33074.

Environment:

Codex Desktop package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
Codex version: 26.715.4045.0
ChatGPT.exe product version observed locally: 150.0.7871.124
OS: Windows 10 Home 22H2, build 19045.6466, x64
CPU: AMD Ryzen 7 5800X
RAM: 64 GB
GPU: NVIDIA GeForce RTX 5070 Ti
NVIDIA driver: 32.0.16.1074
Mouse polling rate: 1000 Hz
Wacom Tablet driver: 6.4.13-4
Codex voice/dictation: disabled from the beginning
Codex CLI: 0.144.4 (not used for this desktop reproduction)

Reproduction:

Fully close Codex Desktop and confirm that all ChatGPT.exe and codex.exe processes have exited.
Mouse movement and FPS gameplay are normal.
Launch Codex Desktop.
Intermittent system-wide mouse stutters/freezes begin. The problem is noticeable during FPS gameplay because even a brief input stall is disruptive.
Fully close Codex Desktop again.
The mouse stuttering stops.
Launching Codex again reproduces the problem.

I initially suspected the Wacom driver, but the following tests did not reliably eliminate the symptom:

Disconnecting the Wacom Intuos did not stop the stuttering.
Stopping the Wacom Professional Service did not stop the stuttering.
The mouse polling rate was already 1000 Hz.
After reinstalling the Wacom driver, the mouse remains smooth while Codex is fully closed, but the stuttering returns after launching Codex.

The repeatable correlation is Codex Desktop running versus fully exited. This appears to be an actual mouse/input stall during FPS gameplay, not only a cosmetic cursor flicker.

Expected behavior:

Launching or using Codex Desktop should not cause system-wide mouse input stuttering or affect FPS gameplay.

Could you investigate whether this is related to the Codex Desktop frontend, WebView/Chromium rendering, or Windows presentation/input handling?

Additional observations from further testing:

I tested Codex briefly on another Windows PC used by my wife. That machine did not show the same mouse stutter during startup or basic task use. The test duration was short, but there was no behavior similar to the stutter seen on my main PC.
I also found other user reports online describing that after opening Codex, users may need to wait around 30-40 seconds before the app becomes normally usable.
On my main PC, mouse stutter can also occur while items under the Scheduled section are running, not only during initial app startup.
The same type of stutter still occurs when viewing other content, switching/opening tasks, and creating a new task.

This suggests the issue may not be caused by account data or one specific task alone. It may depend on Codex startup/task-state refresh/background task activity interacting with a specific hardware/driver/platform combination.

I’m seeing the same issue on Windows.

Environment:

OS: Windows 10 Pro 22H2, build 19045
Codex package: OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0
Codex version: 26.730.8199.0
CPU: Intel Core i7-8550U, 4 cores / 8 logical processors
RAM: 32 GB
Mouse devices tested: wired USB mouse and built-in touchpad

Symptoms:

System-wide mouse pointer stutter happens when Codex is launching or actively working.
The stutter lasts roughly during the Codex startup phase, around 30 seconds.
It is not limited to the Codex window.
The same behavior happens with a wired mouse and the touchpad.
Video playback and audio continue smoothly during the mouse stutter.
The system does not freeze visually; the issue appears to affect pointer/input responsiveness specifically.
Overall CPU usage does not need to exceed ~30-40%, and the system handles unrelated 100% CPU workloads without mouse stutter.

Things tested:

Disabled antivirus manually.
Tested with wired mouse and touchpad.
Lowered Codex process priority to BelowNormal.
Restricted Codex processes to 2 logical CPUs via processor affinity.
Tested both boosted and non-boosted Windows power plans.
Checked that memory is not under pressure: around 16-18 GB free out of 32 GB during reproduction.

Observed locally:

Multiple ChatGPT.exe processes are spawned by the Codex package.
One or more ChatGPT.exe renderer/main processes show CPU activity during the stutter, but there is no full system CPU saturation.
The issue appeared after a Codex update; I did not observe this behavior in earlier versions.

This looks very similar to the startup/task-switching system mouse stutter described in this issue.

I can reproduce the same launch-only, system-wide mouse stutter on the current Windows Store build.

Environment

Codex Desktop: 26.803.5235.0 x64
Windows 11 Home 25H2, build 26200.8973
CPU/RAM: Intel i7-11700F / 32 GB
GPU: RTX 3070, NVIDIA 32.0.16.1074 (610.74)
Displays: 2560x1440 @ 165 Hz + 1920x1200 @ 59.95 Hz
Mouse: Razer Viper V2 Pro

Reproduction / duration

Fully close Codex.
Reopen it.
Move the mouse while the UI initializes.
The mouse stutters system-wide, then recovers on its own.

This reproduces on each reopen. The exact recovery point was not stopwatch-marked, but in the measured run the main process started at T+0 and the user was able to send the recovered-state observation by T+39.5 s, so that is an upper bound. This closely matches the roughly 30-second shape reported here.

Important separation from a different persistent-stutter bug

This machine also had an unrelated malformed heartbeat automation retry loop. Deleting that automation produced a strong A/B improvement and removed the persistent stutter/process churn, as documented in #33371. After that loop was removed, the launch-only transient described here still remained, so these appear to be two distinct paths.

Post-cleanup launch timeline from Codex desktop logs

Relative to desktop log start:

+1.335s  app-server handshake complete
+2.033s  primary ready-to-show
+4.163s  primary routes mounted
+4.173s  globalDictation auxiliary window creation begins
+4.198s  avatarOverlay auxiliary window creation begins
+4.239s  main_thread_jank_snapshot count=1
+4.910s  browser backend startup begins
+4.914s  bundled plugin reconcile begins
+5.076s  globalDictation ready
+5.085s  avatarOverlay ready
+8.307s  globalDictation routes mounted
+8.538s  avatarOverlay routes mounted
+11.502s plugin marketplace sync complete
+12.316s browser runtime paths selected
+12.587s plugin reconcile complete
+13.465s normal thread resume begins
+15.506s normal thread resume succeeds

The only recorded main-thread jank in the first 120 seconds was at +4.239 s, 41–66 ms after the two auxiliary renderer/window creations began. The broader one-time initialization chain ends at about +15.5 s. There were zero startup errors in the first 15 seconds and no retry loop after cleanup.

Windows/process observations

GPU process started at +427 ms; hardware acceleration was active.
Renderers started at about +1.68 s and +4.82 s; bundled codex.exe at +1.71 s.
No matching GPU reset, USB reconnect/re-enumeration, PnP timeout, WER, or app/system warning/error in the launch window.
Settled 20-second baseline after recovery:
- DPC avg 0.198%, max 0.482%
- interrupt avg 0.348%, max 1.059%
- processor queue stayed 0
- Codex GPU avg 0.07%, max 1%
- DWM GPU avg 7.21%, max 11%
No sustained CPU, disk, RAM, ISR, or DPC saturation was found.

This does not yet prove which initializer causes the input hitch, but the strongest time correlation is the +4.2–8.5 s auxiliary renderer bootstrap; plugin/browser/runtime/thread initialization continues to +15.5 s and is the next candidate. HID topology watcher is loaded, but there were no HID/Micro discovery failures or fallback-scan logs to correlate it with this launch.

I can capture a startup WPR trace with CPU/GPU/DesktopComposition providers if maintainers want a trace from build 26.803.5235.0; I would prefer to share it privately because ETL files can contain local paths/process metadata.

Follow-up: cold task switching also reproduces the transient system-wide stutter on 26.803.5235.0

Correction to my previous update: the remaining transient is not strictly launch-only. On the same Windows system and current Store build (26.803.5235.0), I also observe severe system mouse/UI stutter when opening a task that has not yet been opened in the current app session. Switching away and revisiting that same task produces a much smaller disturbance.

This cold-versus-warm observation is qualitative. I did not instrument exact click-to-usable latency, so I am not claiming a numeric A/B duration.

Data-quality note

I am explicitly excluding one preliminary task-switch observation because it overlapped WPR trace merge/finalization work. That observation was recorder-contaminated; none of its timing or process attribution is used below.

All measurements below come exclusively from a separate, controlled task-switch capture.

Controlled cold-task trace

Codex Desktop: 26.803.5235.0 x64
WPR profiles: CPU, GPU, and Desktop Composition; file mode
Controlled interaction window: 45 seconds
ETL timestamp span including provider/rundown activity: 23:38:23.833–23:39:29.942Z
The switch instruction was received at 23:38:35.001Z; the exact mouse-click time was not separately instrumented
The coordinated cold-load burst occupied approximately trace seconds 23–32 (23:38:46.8–23:38:55.8Z) and had subsided by second 33
ETW/WPR events lost: 0

Peak sampled CPU time in one-second buckets:

Process/component	Peak CPU time	Trace second
`ChatGPT.exe` main process	~927 ms	23
`ChatGPT.exe` renderer	~1,437 ms	24
`ChatGPT.exe` GPU process	~415 ms	24
`codex.exe` app-server	~1,774 ms	25
`dwm.exe`	~604 ms	31

Values above 1,000 ms are aggregate process CPU time across multiple threads, not single-core utilization percentages. Compared with trace seconds 33–42 (a conservative comparison window that includes a separate app-server spike at second 35), mean sampled CPU time was approximately 10.5x higher for the main process, 6.1x for the renderer, 10.6x for the GPU process, 5.1x for the app-server, and 5.2x for DWM.

Peak provider event counts in one-second buckets:

Provider	Peak event count	Trace second
`Microsoft-Windows-DxgKrnl`	51,420	24
`Microsoft-Windows-DirectComposition`	31,546	31
`Microsoft-Windows-Win32k`	13,519	31

Across the same 10-second burst, aggregate DPC+ISR duration was ~1.476 s. About 71% of that duration resolved to nvlddmkm.sys / dxgkrnl.sys; the worst one-second bucket contained ~151.0 ms DPC plus ~75.9 ms ISR time. This aligns with the graphics/compositor burst, but it is not sustained DPC/ISR saturation and does not establish the NVIDIA driver as the root cause.

The peaks are tightly clustered across the app-server, desktop main process, renderer, GPU/kernel graphics path, Win32k, and compositor during the cold task load. My current interpretation is that first-load task hydration/rendering triggers the workload and the graphics/composition path amplifies the visible input hitch. The trace does not yet distinguish whether hydration, renderer behavior, DirectComposition/DWM, or the GPU driver is the primary defect.

Cold-load process fanout

The same 10-second window contained 60 process starts; 54 had already stopped by the end of the window. This included 32 short-lived git processes. The only six still running at second 32 were three app-server child pairs of node_repl.exe + node.exe, created in three waves at approximately 23:38:48.06Z, 23:38:51.31Z, and 23:38:54.28Z. Those waves align with the three app/renderer/compositor lobes in the trace. All six later stopped within the capture.

This strengthens the first-load initialization interpretation, but the ETL process data alone cannot determine whether each pair belongs to thread, plugin, MCP, or workspace setup.

I am not attaching the raw ETL publicly because it can contain local paths, process command lines, and other machine/session metadata. I can provide it through a maintainer-designated secure/private channel, or provide additional sanitized exports publicly if useful.

I can reproduce a very similar symptom on the Windows Codex desktop app: after launch, the entire PC can become severely laggy for about 3 minutes. Left-clicks and general input are delayed system-wide, while the Codex CLI remains unaffected.

There is no obvious sustained disk I/O saturation during the episode. I checked the currently running PowerShell processes specifically because of #36025: I did not observe a stream of short-lived PowerShell children or repeated Get-CimInstance Win32_Process / performance-counter WMI queries. The PowerShell processes present were long-lived user automations plus a Codex command helper, rather than a restart loop.

That makes this case look closer to the desktop UI/WebView/DWM-initialization or task-list/rendering path described here than to the WMI polling path. I can provide a reproducible startup trace or further process/GPU/UI-delay measurements if useful.

Additional reproduction on 26.810.4967.0: delayed-onset persistent stutter and main-process busy loop

I can reproduce this on a newer Windows Store build. This case extends the startup/cold-task reports here because the severe system-wide mouse drift/stutter appears after several hours of use and then persists while the app appears idle.

Environment

Codex Store package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
ChatGPT.exe product/file version: 151.0.7922.137
Windows 11 Pro 25H2, build 26200.9168, x64
64 GB RAM, 28 logical processors
NVIDIA GeForce RTX 4080 SUPER
NVIDIA driver: 32.0.15.6094

Reproduction and A/B result

Fully start Codex and use it normally.
After roughly five hours, the mouse begins drifting/stuttering system-wide.
Leave the app idle: the high main-process CPU state persists.
Fully quit Codex: mouse behavior returns to normal.

The problem reproduced with normal hardware acceleration and again when launching the signed Store executable directly with --disable-gpu.

For the disabled-GPU run, process command lines confirmed:

root process contained --disable-gpu;
renderers contained --disable-gpu-compositing;
the Chromium GPU process used --use-angle=d3d11-warp-webgl (WARP software rendering);
the process had zero dedicated hardware VRAM usage.

Despite that, the same mouse stutter returned after about five hours. Disabling GPU therefore did not resolve this case and added some WARP CPU work.

Process measurements

Immediately after the disabled-GPU restart:

main ChatGPT.exe: working set ~385 MB, private memory ~291 MB, 69 threads;
complete Codex process tree: working set ~2.27 GB, private memory ~1.34 GB.

At the reproduced fault, across four ~5-second windows:

main ChatGPT.exe: ~128-134% of one logical core continuously (about 4.56-4.80% whole-machine CPU on 28 logical processors);
main-process working set: ~0.95-1.18 GB;
main-process private memory: ~1.02-1.36 GB;
thread count remained ~68;
the app-server was not the sustained hotspot.

After all concurrent diagnostic sampling stopped, a separate 15-second quiet sample still showed:

main-process CPU: 135.3% of one logical core;
working set: 1.016 GB;
private memory: 1.016 GB;
handles: 2,100;
threads: 68.

This makes the sustained load unlikely to be caused only by active output/streaming or the diagnostic commands.

System-level checks during the fault

whole-system CPU: average 13.44%, peak 17.22%; processor queue stayed 0;
DPC time: average 0.08%, peak 0.11%;
interrupt time: average 0.40%, peak 0.61%;
~38 GB memory remained available; no paging pressure;
no sustained ChatGPT/DWM GPU saturation;
no matching display-driver reset, application hang, or resource-exhaustion event;
Windows Error Reporting had previously recorded RADAR_PRE_LEAK_64 for ChatGPT.exe.

The strongest correlation is a sustained Electron/Chromium main-process busy loop plus substantial private-memory growth after extended use, rather than GPU saturation, DPC/ISR pressure, paging, or the Codex app-server. This may overlap with #30021 and #20735.

I am not attaching raw desktop logs or ETL data publicly because they may contain local paths or session metadata. I can provide additional sanitized counters, or capture a short WPR CPU-stack trace for a maintainer-designated private channel if useful.

Additional reproduction on Windows 10 with package 26.810.6296.0

I can reproduce the same system-wide mouse stutter on a newer Windows build. The regression started immediately after updating the desktop app. Fully exiting the ChatGPT/Codex desktop app makes the mouse and the rest of the desktop responsive again.

Environment

OS: Windows 10 Enterprise LTSC x64, build 19044
CPU: AMD Ryzen 5 5600G, 12 logical processors
RAM: 64 GB; about 33 GB free during capture
GPU: NVIDIA GeForce GTX 750 Ti, driver 32.0.15.6094
Virtual display adapters present: OrayIddDriver, GameViewer, and ToDesk
Store package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0
Desktop app version: 26.810.50856, build 6644
Bundled Codex: 0.148.0-alpha.9
Electron: 42.3.0
Bundled Chromium executable version: 151.0.7922.137
Previous package without this system-wide lag: 26.803.10989.0

Reproduction

Start the ChatGPT/Codex Windows desktop app.
Open or run a Codex task.
Move the mouse while the task is active.
Mouse movement and general desktop responsiveness visibly stutter, including outside the app.
Fully exit the desktop app.
The stutter disappears. Reopening the updated app reproduces it.

Measurements during an affected active task

Two consecutive samples showed bundled codex.exe at about 12.0-13.3% of total CPU on a 12-logical-processor system, equivalent to roughly 1.4-1.6 logical cores.
The ChatGPT/Codex process group used about 1.9 GB working set and 2.2 GB private memory.
Renderer, main, and GPU subprocess CPU usage stayed low in the same samples.
No material process disk throughput was observed.
The GPU subprocess was present, and DWM had 3D activity, but neither CPU nor GPU was globally saturated.
Windows Application logs contained no ChatGPT.exe Application Error or Application Hang event after this update.

Local app-log observations

The local Codex logging database was about 156 MB with approximately 89,800 records.
It contained approximately 40,800 TRACE and 24,600 DEBUG records.
Since the update window, repeated warnings included Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell.
Repeated errors also included Custom tool call output is missing for call id.
These messages may be secondary rather than the root cause, but the volume and sustained codex.exe CPU may be useful for correlation.

Expected behavior

Running a Codex task should not cause system-wide pointer or desktop stutter, particularly when the machine still has substantial free memory and no CPU, disk, or GPU saturation.

I am not attaching raw logs because they may contain local paths or session data. I can provide a more focused trace privately if maintainers request one.

I can reproduce this issue on Windows 11 with Codex Desktop 26.810.4967.0.
The mouse cursor started stuttering system-wide after prolonged use with multiple Codex tasks. Minimizing Codex did not help, but fully exiting and restarting the Codex app immediately restored smooth cursor movement.
Additional observations:
The cursor was completely smooth on the Windows UAC secure desktop but started stuttering again after returning to the normal desktop.
The main ChatGPT.exe process consumed approximately 1.3–1.5 logical CPU cores before restarting Codex, compared with about 0.24 after the restart.
GPU utilization was approximately 3%, DWM usage was low, and no matching USB, NVIDIA display, or WHEA errors were recorded.
Interrupts peaked between approximately 481,000 and 569,000 per second, similar to the measurements reported in #33382.
Hardware: Intel Core Ultra 7 270K Plus, NVIDIA RTX 4070 Ti, 32 GB DDR5, 3440×1440 at 99 Hz.

Update after testing the latest Windows build:

After updating from Windows package 26.810.6296.0 to 26.810.7004.0 (internal app version 26.810.52044), the system-wide mouse stutter is no longer reproducible on this machine.

Mouse movement now remains smooth during app startup and while switching between conversations. At this time, version 26.810.7004.0 appears to have resolved the mouse-stutter issue for me.

Update after testing the latest Windows build:

After updating from Windows package 26.810.6296.0 to 26.810.7004.0 (internal app version 26.810.52044), the system-wide mouse stutter is no longer reproducible on this machine.

Mouse movement now remains smooth during app startup and while switching between conversations. At this time, version 26.810.7004.0 appears to have resolved the mouse-stutter issue for me.

this solved the issue also for me

Windows Codex app causes mouse stutter during startup and task switching without CPU/Disk saturation #33074

Description

Summary

Environment

Symptoms

Reproduction

Diagnostics already performed

Local profile/cache observations

WPR/WPA/xperf evidence

Codex logs

Expected behavior

Actual behavior

Notes

Activity

github-actions commented on Jul 14, 2026

Neontetra8492AI commented on Jul 19, 2026

Zoro8818 commented on Jul 28, 2026

sens2115 commented on Aug 6, 2026

catchitin commented on Aug 8, 2026

Environment

Reproduction / duration

Important separation from a different persistent-stutter bug

Post-cleanup launch timeline from Codex desktop logs

Windows/process observations

catchitin commented on Aug 8, 2026

Follow-up: cold task switching also reproduces the transient system-wide stutter on 26.803.5235.0

Data-quality note

Controlled cold-task trace

Cold-load process fanout

VIEWVIEWVIEW commented on Aug 13, 2026

canglang888888 commented on Aug 15, 2026

Additional reproduction on 26.810.4967.0: delayed-onset persistent stutter and main-process busy loop

Environment

Reproduction and A/B result

Process measurements

System-level checks during the fault

silentjsy commented on Aug 15, 2026

Additional reproduction on Windows 10 with package 26.810.6296.0

Environment

Reproduction

Measurements during an affected active task

Local app-log observations

Expected behavior

R-S1978 commented on Aug 15, 2026

silentjsy commented on Aug 16, 2026

R-S1978 commented on Aug 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions