›_ Codex Issues
Codex Issues / #33438

Windows x64 ChatGPT/Codex 26.707.9981.0: repeated 0xC06D007F and 2-3 second system input lag when opening a new task

Open 💬 9 comments Opened Jul 15, 2026 by prkbll
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

App and system

  • App package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Package status: Ok
  • OS: Windows 11 Pro, version/build 10.0.26200
  • Architecture: x64 / 64-bit
  • CPU: 11th Gen Intel Core i7-1185G7
  • RAM: 31.7 GB
  • GPU: Intel Iris Xe Graphics, driver 32.0.101.7077

Problem

Every time I open a new task, the task pane is initially blank for roughly 2-3 seconds. During that interval, the mouse pointer becomes extremely heavy and delayed, as if the entire input path is stalling. The task content then appears and pointer movement returns to normal.

Windows records an Application Error event for ChatGPT.exe during the same operation, and Windows creates a new crash dump. The app often remains open despite the event.

The repeated event signature is:

Faulting application: ChatGPT.exe
Faulting module: unknown
Exception code: 0xc06d007f
Application path: C:\Program Files\WindowsApps\OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

The dumps are approximately 10-11 MB each and are written under %LOCALAPPDATA%\CrashDumps.

Reproduction

  1. Start ChatGPT/Codex on Windows.
  2. Create or open a new local Codex task.
  3. Move the mouse while the new task pane is loading.
  4. Observe severe pointer/input lag for about 2-3 seconds while the pane is blank.
  5. Check Windows Application events and %LOCALAPPDATA%\CrashDumps.
  6. A new ChatGPT.exe event with exception 0xc06d007f and a corresponding dump are created.

This reproduces repeatedly, including with a newly created task.

Troubleshooting already performed

  • Microsoft Store reported no newer build.
  • Ran Windows Package Manager repair successfully. It repaired the same 26.707.9981.0 package; the error resumed immediately.
  • Completely uninstalled and reinstalled the Store package. Windows created a brand-new package-state directory. The same exception resumed on the fresh installation.
  • Disabled Browser full CDP/developer access.
  • Rotated logs_2.sqlite and allowed Codex to create a fresh log database. The old database was about 132 MB; behavior was unchanged with a fresh database.
  • Reduced the active .codex\sessions hot path from 76 JSONL files totaling about 151.9 MB to one current session file totaling about 4.1 MB. Behavior was unchanged, and the same exception continued.
  • PB Books/project files, memories, skills, authentication, and configuration were not involved in these tests.

On the one-session test, two identical 0xc06d007f events appeared within the first minute after restart.

Expected behavior

Creating or opening a task should not stall system mouse/input handling, and ChatGPT.exe should not generate an Application Error event and crash dump for each operation.

Related reports

  • #28855 - Windows system mouse/input lag
  • #29543 - 2-3 second freeze during first input in every new conversation
  • #28109 - session-directory scanning and brief input freezes
  • #33045 - Windows x64 performance regression in the unified 26.707 app
  • #33381 - same package build and 0xc06d007f on ARM64; this report is x64 and may have a different failing native module

Diagnostics and privacy

I have retained the minidumps and a screen recording locally. I am not attaching raw dumps publicly because minidumps may contain process memory, but I can provide them privately to an OpenAI maintainer or support channel.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 5 days ago

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

  • #33375

Powered by Codex Action

HopeCollector · 5 days ago

Confirming this on 26.707.9981.0 — same 0xC06D007F crash-loop + input lag

Reproducing the exact symptom described here. Adding independent diagnostic data in case it helps narrow the root cause (looks identical to the serialport.node delay-load theory in #33375).

Environment

  • App: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0 (Microsoft Store, installed 2026-07-14)
  • OS: Windows 11 Pro, build 10.0.26200
  • CPU: 12th Gen Intel Core i7-1260P
  • RAM: 31.2 GB
  • GPU: Intel Iris Xe + NVIDIA T550 Laptop GPU

Symptom

  • Opening or switching to a task/conversation causes a 2–3s freeze; the task pane stays blank and mouse/keyboard input lags system-wide during that window.
  • Each event spawns a WerFault.exe that writes a ~10.6 MB crash dump to %LOCALAPPDATA%\CrashDumps, with disk-write bursts around ~490 MB/s — this is what shows up as "system process high disk I/O" in Resource Monitor.

Crash data (Application log, Event ID 1000, ChatGPT.exe)

  • 100 crashes in the last 6 hours (first 06:49:10 → last 11:06:15 local).
  • Exception code: 0xc06d007f on every crash (single distinct code).
  • Faulting module: unknown (renderer/dynamic code — no on-disk DLL attributed).
  • Restarting the app does not help: a fresh process crashed 15 times in 15 minutes and stayed laggy afterward, matching #32769.

Already tried, ineffective

  • Full app restart / relaunch.
  • (Per #33438 others also confirmed: winget package repair, full uninstall/reinstall, and shrinking the sessions directory — none fixed it.)

Notes

  • 26.707.9981.0 is currently the newest available build (no fixed build to upgrade to).
  • winget only ships the Codex CLI (0.14x), not this Store desktop app, so there's no supported downgrade path.
  • The single, consistent 0xc06d007f across 100 crashes strongly supports the native-module delay-load hypothesis in #33375 (serialport.node importing N-API/libuv procs missing from the ChatGPT.exe/Electron runtime).
321Fontsize · 4 days ago

I have same question.

iwillmissu · 4 days ago

I have same question.please fix.

Layla-1986 · 4 days ago

我是在更新版本重置额度后，非常明显出现了这些问题，之前非常丝滑，请尽快修复

HopeCollector · 4 days ago

Update: build 26.715.2236.0 appears to fix this

After updating from 26.707.9981.0 → 26.707.12708.0 (which did not help — same 0xc06d007f crash-loop) → 26.707... now 26.715.2236.0, the crashes have stopped for me.

Before (on 26.707.9981.0 / 12708, Windows 11 x64):

  • ~100 ChatGPT.exe crashes / 6h, Event ID 1000, exception 0xc06d007f, faulting module unknown
  • Every new/switched task spawned a WerFault.exe writing a ~10 MB minidump (disk-write bursts ~490 MB/s) → 2–3s system-wide input lag
  • Persisted across restart, package repair, full reinstall, and session-dir reduction

After (26.715.2236.0):

  • Active since app relaunch; normal usage including opening/switching multiple tasks
  • 0 crashes (Event ID 1000) since the new build started
  • No new minidumps in %LOCALAPPDATA%\CrashDumps (newest one predates the update)
  • No WerFault activity, input lag gone — subjectively back to normal

This lines up with the serialport.node delay-load root cause discussed in #33375: 26.715 seems to have corrected the native-module packaging for the app's Electron runtime.

Note: this is an empirical confirmation from the field — I don't see 26.715 documented in the changelog yet, so it may be worth an official note / closing this once confirmed. Environment: Windows 11 Pro (build 26200), i7-1260P, x64. Happy to share minidumps from the old build privately if useful.

prkbll · 3 days ago

Resolved after the July 16, 2026 Windows app update.

The Microsoft Store upgraded the app from 26.707.9981.0 to 26.715.2305.0. Since that update, opening a new task no longer causes the 2-3 second system mouse/input lag, and the repeated ChatGPT.exe 0xC06D007F Application Error/crash-dump behavior has stopped.

No PB Books project data, Codex memories, skills, authentication, or configuration had to be removed. I will update this issue if the problem returns.

shlee1615 · 3 days ago

Adding a sanitized Windows x64 data point that closely matches this issue and shows the input stall can persist after updating beyond 26.707.

Current environment

  • Codex/ChatGPT Windows package: 26.715.2305.0
  • Windows 11 Home x64, build 10.0.26200
  • AMD Ryzen AI MAX+ 395, 16C/32T
  • 123.6 GiB RAM (~88.3 GiB available during reproduction)
  • AMD Radeon 8060S, driver 32.0.23033.5002 (2026-06-29)
  • Codex CLI recorded in affected sub-agent metadata: 0.145.0-alpha.18

Symptom and A/B result

  • The mouse pointer stutters/jumps across the whole desktop and in other applications while multiple Codex agents are active.
  • Keyboard input is mostly unaffected.
  • Minimizing the Codex window for 20 seconds made no noticeable difference. This suggests visible-window painting alone is not required; background app-server/session/IPC/GPU work may still be involved.

Matching crash history

Windows Event Log recorded the same signature reported here under package 26.707.9981.0:

  • 2026-07-15: 2 ChatGPT.exe Application Error events
  • 2026-07-16: 71 ChatGPT.exe Application Error events
  • faulting module: unknown
  • exception: 0xc06d007f

The current 26.715.2305.0 build has not produced a new matching crash event yet, but the system-wide pointer stutter remains. This may mean the crash was mitigated while the underlying input-stall path persists.

New multi-agent/session amplification evidence

Safe first-line metadata inspection (no conversation contents read) found:

  • local sessions tree: 1,383 rollout files, 13.56 GiB total
  • 47 files >100 MiB; 4 files >500 MiB
  • current day: 27 files, 2.48 GiB total
  • 10 current-day files >200 MiB
  • all 10 large files are confirmed originator: Codex Desktop, source: subagent.thread_spawn, depth 1, with the same parent thread
  • each child rollout is approximately 242.3–260.1 MiB
  • three of those files were still actively locked during inspection

This looks like each sub-agent is materializing a very large parent state instead of using a compact/bounded snapshot or reference.

Local logging state also appears unhealthy:

  • logs_2.sqlite: 2,022.25 MiB
  • 573,735 log rows
  • about 941.5 MiB represented by SQLite free pages
  • largest estimated log volumes: stream-event utilities (~196.8 MiB), SSE responses (~177.2 MiB), MCP connection manager (~102.8 MiB)

Resource measurements during the problem

There was no sustained system saturation:

  • 20-second total CPU: 11.4% average, 15.9% 1-second peak
  • ChatGPT UI: ~0.69% average system CPU
  • Codex backend: ~0.09% average system CPU
  • ~88 GiB RAM available; no paging pressure
  • processor queue length: 0
  • 10-second GPU sample: ChatGPT GPU process ~1.0% average / 1.53% peak; DWM ~0.72% / 1.32%
  • 15-second mouse-movement sample: DPC time 0.179% average / 0.434% peak; interrupt time 0.390% / 0.676%; queue length remained 0
  • no Windows Display provider reset events in the last 7 days

However, footprints were large:

  • high-memory Codex backend: ~2.22 GiB private memory
  • ChatGPT main: ~926 MiB private
  • renderer: ~746 MiB private
  • GPU process: ~400 MiB private
  • dwm.exe: ~2.20 GiB private memory, 143 threads, 4,435 handles

An orphaned Python benchmark launched from a prior Codex visualization/session had also accumulated ~39,952 CPU seconds with no live parent, suggesting child-process lifecycle cleanup may be another contributor.

Interpretation

This does not look like two literal mouse-control loops conflicting. The measurements are more consistent with short event-loop/IPC/session-serialization or compositor frame-time stalls that do not show up as high sustained average utilization. High-frequency pointer movement exposes such stalls more clearly than keyboard input.

The new sub-agent evidence may connect this issue with #28855 (system input lag), #21134 (large hot thread / renderer / log churn), #28109 (large sessions directory input freezes), and #29674 (TRACE/SQLite growth).

Requested engineering checks

  1. Avoid full parent-rollout materialization for every sub-agent; use bounded compact snapshots, references, or copy-on-write.
  2. Keep session scanning, reconstruction, serialization, and log writes off UI/main-thread latency paths.
  3. Add backpressure/coalescing for stream/state IPC updates.
  4. Bound/rotate/compact logs_2.sqlite and avoid unrestricted TRACE/SSE payload persistence.
  5. Use Windows Job Objects or equivalent lifecycle cleanup for agent-launched child processes.
  6. Add a Windows multi-agent regression test that measures pointer/frame latency, not only average CPU/GPU.

No session contents, raw JSONL/SQLite files, project paths, tokens, or dumps are included.

prkbll · 2 days ago

Follow-up: crash loop remains fixed, but cold-start pointer drag persists on 26.715.4045.0

The original per-task 0xC06D007F / WerFault / crash-dump loop remains resolved after the 26.715 update. However, I can now reproduce a residual system-wide mouse heaviness during a cold app launch, even while remaining on the Work home screen with no task/thread open and no active agents.

Measured on Windows 11 x64 with package OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0:

  • ChatGPT desktop process start: 2026-07-18 14:11:45.104 local
  • Codex backend start: 2026-07-18 14:11:47.535 local
  • Mouse movement returned to normal roughly when the screenshot was captured/attached: 2026-07-18 14:12:59.451 local
  • Observed cold-start drag window: approximately 72-74 seconds
  • The first thread/resume was not logged until 14:12:58, when I opened this task to report the observation; the drag occurred while the app was sitting on the home screen
  • No Windows Application Error / WER event and no new matching 0xC06D007F crash dump occurred during this interval
  • After that cold start, reopening the first work task can still produce about 1 second of pointer drag; subsequent task openings appear normal

The screenshot timestamp is only an approximate endpoint for the manually observed pointer recovery, but the process and thread-resume timestamps are log-derived.

This appears consistent with the distinction in the latest report above: 26.715 mitigated the native-module crash/minidump path, but some pointer/compositor/event-loop startup latency remains. This reproduction also shows that the residual stall does not require multiple active agents or opening a large thread.