Windows x64: repeated background crash (0xC06D007F) in serialport.node causes UI freezes during normal use

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

• #33505
• #33491
• #33494
• #33438
• #33375

Powered by Codex Action

同样的问题

Subject: Codex 26.707.9981.0 repeatedly crashes in serialport.node

The Codex Windows desktop app repeatedly becomes unresponsive and crashes every 20–60 seconds. The window may recover automatically because the failed process is restarted.

Affected Codex build

• Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Codex version: 26.707.9981.0
• ChatGPT.exe version: 150.0.7871.115

Reproduction environments

1. Windows 11 Insider Preview, build 26300
2. Windows 11 Pro 25H2, build 26200.8875 (fresh virtual machine)

The issue reproduces on both systems with the same Codex package.

Observed behavior

• Repeated Event ID 1000 and 1001 entries
• Exception code: 0xc06d007f
• The UI can recover after an auxiliary ChatGPT.exe process is replaced
• Resetting and reinstalling Codex does not resolve the issue
• Restarting Windows does not resolve the issue
• Removing the VS Code Codex extension does not resolve the issue

Native module comparison

• Module: @serialport/bindings-cpp/build/Release/serialport.node
• Dependency chain:

@worklouder/device-kit-oai
-> @worklouder/wl-device-kit
-> serialport
-> @serialport/bindings-cpp

• Size: 229376 bytes
• SHA-256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006
• The SHA-256 is identical on both machines.

WinDbg result

• Failure bucket: APPLICATION_FAULT_c06d007f_serialport.node!Unknown
• Faulting native module: serialport.node
• The crash occurs during serialport.node initialization through LoadLibraryExW.

The DelayLoadInfo structure identifies the exact failed import:

• DLL: node.exe
• Procedure: napi_module_register
• LastError: ERROR_PROC_NOT_FOUND (0x7f)
• Outer exception: 0xc06d007f

PE export/import verification

• serialport.node delay-imports napi_module_register from node.exe.
• During the crash, the resolved module handle points to ChatGPT.exe.
• ChatGPT.exe does not export napi_module_register.
• The bundled chrome.dll does export napi_module_register.
• chrome.dll contains all 57 Node-API/LibUV symbols required by serialport.node.

Assessment
This strongly indicates an Electron/Node delay-load redirection or native-module packaging regression in Codex 26.707.9981.0. It does not appear to be caused by a damaged installation, VS Code extension, VC++ Runtime, UCRT, or a single Windows Insider build because the same binary and failure reproduce on two Windows builds.

Please investigate the bundled @worklouder device-kit / serialport.node integration and the mapping of node.exe delay imports to the Electron runtime.

Failure hash from WinDbg:
{4927e390-5f61-4b71-57ae-af5d5edb1937}

A full memory dump exists locally, but it has not been attached because it may contain session or account data. A sanitized WinDbg excerpt can be provided if required.

i have the same problem

I have the same problem, it's almost unusable now and really needs to be fixed!!!!!!!!!!!!!!!!!!!!

I can independently reproduce and locally verify the same failure on another x64 machine.

Environment:

• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• ChatGPT.exe product version: 150.0.7871.115
• Windows 11 25H2, build 26200.8655, x64
• VC++ runtime: 14.51.36247, x64

Reproduction and impact:

1. Send a message and wait for the response, or let a Codex task finish.
2. Windows records repeated Application Error Event ID 1000 entries for the still-running ChatGPT.exe process.
3. Every sampled failure has exception 0xc06d007f, faulting module unknown, and WER event type MoAppCrash.
4. In one 30-minute window I recorded 27 Event ID 1000 crashes and 55 WER Event ID 1001 records.
5. WER repeatedly creates memory.hdmp; Windows Error Reporting becomes the dominant disk writer and can drive the NVMe SSD to 100% active time.

A complete uninstall, Windows restart, and clean reinstall did not help because the same 26.707.9981.0 build was installed again.

I also verified the native-module chain in the installed package:

@worklouder/device-kit-oai
  -> @worklouder/wl-device-kit
  -> serialport
  -> @serialport/bindings-cpp/build/Release/serialport.node

Using Visual Studio dumpbin on the locally installed binaries:

serialport.node delay-load target: node.exe
failed/required procedure: napi_module_register

ChatGPT.exe exports napi_module_register: NO
chrome.dll exports napi_module_register: YES

This independently confirms the same Electron/Node delay-load redirection or native-module packaging regression described above. It is not resolved by repairing or reinstalling the app, and it is not caused by missing VC++ runtime files.

As a temporary mitigation only, I disabled Windows Error Reporting for the current user to stop the repeated full-memory dumps from saturating the SSD. The underlying serialport.node initialization failure remains and needs an app update (for example, a corrected serialport prebuild/mapping or disabling the affected CodexMicro device-kit path).

Independent reproduction on Windows x64, with a minidump captured during an actual UI hang.

Environment

• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• ChatGPT/Chromium product version: 150.0.7871.115
• Windows 11 25H2, build 26200.8875, x64
• 15.78 GB RAM; about 4-5 GB remained available during reproduction

Observed behavior

• During ordinary task use, the visible app became Responding=False for about 10 seconds and then recovered.
• Windows recorded Application Error event ID 1000 at the same time.
• Exception code: 0xc06d007f
• Faulting module shown by Event Viewer: unknown

I temporarily enabled WER LocalDumps and captured the matching minidump. LLDB showed:

KERNELBASE!RaiseException
serialport.node
chrome.dll!uv_dlopen

The delay-load exception information identified the exact failed lookup:

szDll       = node.exe
szProcName  = napi_module_register
dwLastError = 127 (ERROR_PROC_NOT_FOUND)

The native addon is bundled under:

@worklouder/device-kit-oai
  -> @worklouder/wl-device-kit
  -> serialport
  -> @serialport/bindings-cpp/build/Release/serialport.node

PE import/export verification on the installed package:

• serialport.node requires 57 Node/N-API/uv symbols.
• ChatGPT.exe exports only 2 symbols and provides 0 of those 57.
• Bundled chrome.dll provides all 57 required symbols.

This supports an Electron win_delay_load_hook / native-addon packaging regression rather than an out-of-memory condition.

Also ruled out locally:

• CPU and disk were lightly loaded during the hang.
• Nahimic processes/tasks were stopped, Windows was restarted, and the injected Nahimic DLLs were absent; the failure still reproduced.
• Microsoft Store repair/restart did not resolve it.

I am not attaching the raw dump or session logs because they may contain account/session data, but I can provide a sanitized debugger excerpt if maintainers need it.

same problem

same problem

WinDows11 Microsoft Windows版本 25H2(OS 内部版本 26200.8875) 同样的问题

Here is my case with workaround by Codex.

Environment

• Windows 11 25H2 x64, build 26200.8875
• Executable: ChatGPT.exe (150.0.7871.115)
• Affected packages:
• OpenAI.Codex 26.707.9981.0 x64
• OpenAI.Codex 26.707.12708.0 x64
• Windows Application event: Event ID 1000
• Exception code: 0xC06D007F

Symptoms and frequency

One or more child ChatGPT.exe processes can repeatedly crash while other processes remain alive, producing a large number of Windows Error Reporting events.

Package versions were correlated with the package transition time:

| Package version | Count | First crash (UTC) | Last crash (UTC) | Active-period frequency |
|---|---:|---|---|---|
| 26.707.9981.0 | 613 | 2026-07-15 15:51:27 | 2026-07-16 07:25:52 | About once every 36.5 seconds |
| 26.707.12708.0 | 26 | 2026-07-16 07:26:18 | 2026-07-16 07:50:52 | About once every 59 seconds |

Gaps longer than ten minutes were excluded from the active-period frequency. The first local crash at 2026-07-15 15:51:27 UTC closely matches the reported rollout onset. The newer package started producing the same exception immediately, so it does not appear to contain a fix.

Root cause in plain language

This does not look like a missing save directory or a damaged user profile. It looks like a binary compatibility mismatch between a native component bundled with the app and the executable loading it.

The likely sequence is:

1. A server-controlled rollout enables the optional Codex Micro/Work Louder device integration.
2. The app tries to load serialport.node, the native component used for serial-port communication.
3. That component expects 53 Node N-API functions, including napi_create_function and napi_module_register, to be available from its host.
4. The packaged ChatGPT.exe does not export those functions. Its observable exports are only GetHandleVerifier and IsSandboxedProcess.
5. The Windows loader cannot resolve the required functions. This produces ERROR_PROC_NOT_FOUND (127), surfaced as the VC++ delay-load exception 0xC06D007F.
6. The app restarts the failed child process or retries the same initialization, creating the repeated crash loop.

In simple terms, the bundled native component uses a plug that the host executable does not provide. The file exists, but Windows cannot connect the functions it requires.

The binary mismatch is directly observable. Activation by the rollout is an inference supported by the matching onset time and by the result of suppressing only the affected optional integration. Developer symbols or a loader stack trace would be needed for final confirmation.

Binary evidence

The updated ChatGPT.exe still exports only:

GetHandleVerifier
IsSandboxedProcess

It has no napi_* or node_api_* exports. The bundled x64 module follows this dependency path:

@worklouder/device-kit-oai
  -> @worklouder/wl-device-kit
  -> serialport
  -> @serialport/bindings-cpp/build/Release/serialport.node

The bundled serialport.node imports 53 N-API functions from node.exe, including napi_create_function and napi_module_register.

ChatGPT.exe SHA-256:
28C3E8B6C55FFF39ECB12A5EB27F493ABF997804247517AA7A46C277CA5D9E93

serialport.node SHA-256:
2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

How another user can check whether it is the same problem

Check the crash signature before applying the mitigation. It is a strong match when all of the following are present:

• Repeated Event ID 1000 failures for ChatGPT.exe.
• Exception code 0xC06D007F.
• An affected x64 OpenAI.Codex package.
• The app remains open while child processes keep crashing, often causing lag or short freezes.
• ChatGPT.exe has no N-API exports.
• The bundled serialport.node imports N-API functions from node.exe.

If the exception, executable, or import/export mismatch differs, it should be investigated as a separate problem rather than applying this mitigation automatically.

Workaround using Codex

This is an unofficial, reversible mitigation. It disables only the optional Codex Micro/Work Louder hardware integration; it should not modify the signed WindowsApps package or user data.

Give Codex this single prompt:

Determine whether this is the same Windows x64 crash as GitHub issue #33518.
Use #33381 only as the technical reference for the N-API/serialport root cause.

Phase 1 — Verify without making changes

1. Read Windows Application Event ID 1000 entries for ChatGPT.exe.
2. Identify the Windows version and installed OpenAI.Codex package version.
3. Report in UTC:
   - exception code;
   - first and last crash times;
   - crash count;
   - active-period frequency, excluding gaps longer than ten minutes.
4. Confirm that ChatGPT.exe was running during the measured period.
5. Inspect the packaged x64 binaries and verify both conditions:
   - ChatGPT.exe has no napi_* or node_api_* exports;
   - serialport.node imports napi_create_function and napi_module_register
     from node.exe.

Proceed only if the repeated ChatGPT.exe crashes use 0xC06D007F and the
N-API import/export mismatch is confirmed. Otherwise, stop and report which
condition did not match. If it matches, summarize the evidence and ask me
before creating any files.

Phase 2 — Create the workaround after approval

1. Create the files in the current Codex workspace.
2. Create a CommonJS preload hook that intercepts only
   @worklouder/device-kit-oai and returns the minimal no-op API required by
   the app, preventing serialport.node from loading.
3. Create a PowerShell launcher that:
   - refuses to run while any ChatGPT.exe process exists;
   - discovers the installed OpenAI.Codex package and AUMID from its manifest;
   - temporarily prepends the hook through NODE_OPTIONS;
   - launches the AppX entry through shell:AppsFolder;
   - restores the previous user-scope and session-scope NODE_OPTIONS values
     in a finally block.
4. Do not modify WindowsApps, the package manifest, or application data.
5. Validate the JavaScript and PowerShell syntax and show the generated files
   before execution.

Phase 3 — Verify after I approve execution

1. Record the Event ID 1000 count immediately before launch.
2. Launch the app with the generated workaround.
3. Confirm that ChatGPT.exe remains running.
4. Compare the new crash count with the earlier active-period frequency.
5. Report the observation duration, expected crashes at the previous rate,
   actual crashes, and latest crash time in UTC.

Before running the generated launcher, completely exit Codex and confirm that no ChatGPT.exe processes remain. Review the generated files before execution. The launcher must preserve any existing NODE_OPTIONS value and restore it even if startup fails.

Rollback consists of closing Codex, restoring the recorded previous NODE_OPTIONS values if necessary, and deleting the generated hook and launcher. The workaround should be removed after an official fixed package is installed.

Verification on this system

• Mitigated process launch: 2026-07-16 07:52:09 UTC
• Latest check: 2026-07-16 09:40:51 UTC
• Continuous runtime at check: about 108.7 minutes
• Running ChatGPT.exe processes: 9
• Crashes after the mitigated launch: 0
• Latest crash remained: 2026-07-16 07:50:52 UTC

At the previous rate for 26.707.12708.0, approximately 110 crashes would have been expected during that runtime. None occurred. This shows that the crash loop stopped while the mitigation was active, but it does not show that the unchanged package itself was fixed.

Limitation

Codex Micro/Work Louder hardware integration is unavailable for that launch. A permanent fix requires the optional integration to be loaded safely or the native module and host exports to be packaged with compatible ABI expectations.

Independent x64 reproduction confirming this issue.

Environment:

• Windows 11 x64, 16 GB RAM (WER reports build family 26100/26200)
• Microsoft Store package OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• The same app version was installed before and after the regression; the machine was reportedly responsive the previous day.

Observed behavior:

• Severe intermittent composer/UI freezes during ordinary Codex use.
• Windows Application Error event 1000 repeatedly records ChatGPT.exe with exception 0xc06d007f.
• WER classification: MoAppCrash, fault module StackHash_0000, P9 PCH_84, bucket fe840c3ed30ba850ddeac7488b0e9f2e.
• The archived WER report identifies OriginalFilename=chrome.exe and IsFatal=1.
• 95 matching crash events were recorded before Windows Repair. Repair did not help.
• After a complete uninstall/reinstall, the newly started process generated 8 more identical crashes within approximately four minutes.
• Current process memory usage was modest and no obvious third-party injected module was found in the readable module list.
• Persistent HTTP/HTTPS/ALL_PROXY user environment variables were empty, so this crash loop is separate from network/proxy instability.

The unchanged client version plus the sudden onset is consistent with the server-side/feature-flag explanation in this issue. Reinstalling the same Store build does not resolve it.

Please consider disabling the CodexMicro/device integration flag for affected Windows x64 clients until a compatible serialport.node/Electron native dependency is shipped.

“https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this method solves the problem!

Additional x64 confirmation on 26.707.12708.0: exact node.exe!napi_module_register delay-load failure

I am seeing the same severe Windows x64 UI-freeze/crash pattern on the newer Store build OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0.

The important additional finding is that a minidump and an on-disk PE export-table check identify the exact unresolved import. On this x64 build, the signed ChatGPT.exe has only 2 named exports and does not export napi_module_register. This aligns with the host-export failure described for ARM64 in #33381, and differs from the assumption in this issue that x64 ChatGPT.exe has a normal N-API export surface.

Environment

• Windows 11 Pro for Workstations, x64, build 26200
• Current app package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Previous package 26.707.9981.0 produced the same 0xC06D007F signature before the Store update
• Executable: app\ChatGPT.exe
• No Work Louder or serial device connected; only a mouse is attached
• The ChatGPT web app in Chrome remains stable

User-visible behavior

• The desktop app becomes unresponsive on essentially every click, including opening Settings.
• The stall can make the rest of the Windows UI feel frozen or severely delayed.
• Event Viewer records Application Hang/crash activity, including repeated ChatGPT.exe Event ID 1000/1001 reports.
• Reinstalling the Store app and clearing the ordinary ChatGPT application-data/cache locations did not resolve it.

Repeated Windows crash signature

Across both 26.707.9981.0 and 26.707.12708.0:

Exception code: 0xc06d007f
Fault offset:   0x00007ffa428b1ada
WER event:      MoAppCrash
WER P8:         c06d007f

Ten local minidumps were captured in approximately three minutes:

Dump count: 10
Total size: 109.58 MB
Oldest: 2026-07-16 01:30:53
Newest: 2026-07-16 01:33:48

Minidump DelayLoadInfo result

A read-only parser decoded exception parameter 0 from a real ChatGPT.exe minidump:

EXCEPTION_CODE=0xC06D007F
LAST_ERROR=0x0000007F (127 / ERROR_PROC_NOT_FOUND)
IMPORT_BY_NAME=1
CURRENT_HMODULE=ChatGPT.exe
CURRENT_PROCEDURE=0x0

Both the delay-import descriptor and the unresolved function-pointer slot belong to:

app\resources\app.asar.unpacked\
node_modules\@worklouder\device-kit-oai\
node_modules\@worklouder\wl-device-kit\
node_modules\serialport\
node_modules\@serialport\bindings-cpp\
build\Release\serialport.node

This establishes the importing module as the packaged serialport.node native addon.

Exact DLL and missing procedure recovered from the packaged PE image

Using the dump-recorded virtual addresses and the exact installed serialport.node, a read-only PE parser recovered:

TARGET_DLL_NAME=node.exe
REQUESTED_PROCEDURE=napi_module_register

The same parser inspected the exact installed ChatGPT.exe export table:

CHATGPT_EXPORT_COUNT=2
REQUESTED_EXPORT_PRESENT_EXACT_CASE=False
REQUESTED_EXPORT_PRESENT_CASE_INSENSITIVE=False
SIMILAR_CHATGPT_EXPORTS=<none>

Binary identifiers:

serialport.node
  Size:   229376 bytes
  SHA256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

ChatGPT.exe
  Size:   4070400 bytes
  SHA256: 28C3E8B6C55FFF39ECB12A5EB27F493ABF997804247517AA7A46C277CA5D9E93

Resulting failure path

serialport.node
  -> delay-loads node.exe!napi_module_register
  -> node.exe is redirected to the Electron host ChatGPT.exe
  -> ChatGPT.exe does not export napi_module_register
  -> GetProcAddress returns ERROR_PROC_NOT_FOUND (127)
  -> VC++ delay-load helper raises 0xC06D007F

Evidence against the earlier WebView2/GPU hypotheses

• The package contains bundled Chromium/Electron artifacts (app.asar, chrome_elf.dll, resources.pak, V8 snapshots).
• Every observed msedgewebview2.exe process identified its host as Windows Widgets or SearchHost, not ChatGPT.
• The same diagnostic window contained no matching Display, WHEA, DxgKrnl, GPU-timeout, or Kernel-Power event.
• The error occurs without a serial device connected and before serial-device I/O would be relevant.

Requested maintainer action

Could the team please verify the x64 26.707.12708.0 package against the hashes above and determine why its ChatGPT.exe export directory contains only two named exports?

Potential mitigations/fixes:

1. Disable or gate the @worklouder/device-kit-oai / serialport integration on affected Windows builds.
2. Do not load the optional device integration when the host lacks the required N-API exports.
3. Ship ChatGPT.exe with the required Node-API export list, or rebuild/package serialport.node for the exact Electron host/runtime.
4. Catch the native-addon load failure so an optional integration cannot repeatedly stall the entire desktop UI.

I will not upload the raw process dump publicly because it can contain private process memory. Sanitized parser output and the read-only PowerShell parsers can be provided, and a dump can be shared privately with maintainers if there is a secure channel.

“[https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this](https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86%E2%80%9D%E2%80%94 this) method solves the problem!

Is a 404

This is correct:
https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86

> “[https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this](https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86%E2%80%9D%E2%80%94 this) method solves the problem! Is a 404 This is correct: https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86

My preliminary findings from GPT 5.6 Pro reasoning:

Is this a legit fix? That you didn't find?
triesmon/bdc20a18ec34108e2608c1294c451f86
Worked for 1m 44s

Yes. It is a technically legitimate, targeted workaround—and I should have found and evaluated it earlier.

It directly matches what your dump proved. The launcher pauses ChatGPT/Codex before its JavaScript starts, intercepts only:

@worklouder/device-kit-oai

and substitutes a no-device stub. That prevents the dependency chain from reaching the incompatible serialport.node that requests node.exe!napi_module_register. It then resumes the app and closes the local debugger connection. It does not modify the signed WindowsApps package, registry, conversations, or application data.

It is more accurately described as a workaround, not a permanent fix. It avoids loading the broken component; it does not rebuild serialport.node or correct the missing export in ChatGPT.exe. A separate user reports that after using it, the freezes stopped and no new 0xC06D007F or MoAppCrash events appeared.

There are important # of cautions: The reason for sharing this

The author tested it on 26.707.9981.0; your installed version is 26.707.12708.0.
It relies on undocumented application internals.
It briefly enables a Node inspector on a random 127.0.0.1 port. That is local-only and short-lived, but still creates a temporary code-injection interface.
GitHub flags the files as containing hidden or bidirectional Unicode characters.
The current script does not appear to pin itself to a specific Codex version, despite the accompanying recommendation to do so.
On injection failure, the current JavaScript records an error, but it does not clearly terminate the newly launched process in every failure path.

The rendered source shows no obvious credential theft, external upload, registry modification, or destructive file operations. Its network activity is directed at the local inspector. Nevertheless, because of the hidden-character warning and mutable Gist, I would not run the original files blindly.

Verdict
Matches your diagnosed defect: Yes.
Credible workaround: Yes.
Official or permanent fix: No.
Safe enough to run unchanged: Not quite.
Did I miss it earlier: Yes.

The correct implementation for your machine is a hardened copy pinned to OpenAI.Codex_26.707.12708.0_x64, with exact file hashes, rejection of hidden bidirectional controls, localhost-only inspector validation, and fail-closed process termination. The underlying vendor fix still needs to come from OpenAI.

I have the exact same issue with a similar setup

Hi all - thanks a lot for the reports and we have disabled the feature for windows at the moment. The config itself might take some time to propagate and would definitely recommend a restart before it takes effect. Please let us know if you are still seeing the issue persistently after restarting in the next couple hours. We are also preparing a proper fix and it is currently in the pipeline.

“https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this method solves the problem!

It works！Thank you

Additional data point from Windows x64 after updating to 26.707.12708.0

I can confirm the same 0xc06d007f / MoAppCrash signature on this Windows x64 machine before the Store update, and I am now monitoring the newer build after restarting Windows and the ChatGPT/Codex desktop app.

Environment

• OS: Microsoft Windows NT 10.0.26200.0, x64
• Current Codex package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Current Codex version: 26.707.12708.0
• Previous failing package observed in Event Viewer: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• PowerShell present on the machine: 7.6.3

Confirmed local crash evidence before the update

Windows Event Viewer recorded repeated Application Error / Windows Error Reporting entries for ChatGPT.exe on 2026-07-16.

Representative local evidence:

Application Error / Event ID 1000
Faulting application: ChatGPT.exe
Faulting package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Exception code: 0xc06d007f
Faulting module: unknown
WER event type: MoAppCrash

The same signature appeared repeatedly between approximately 13:45 and 14:25 local time. Local CrashDumps were also created for ChatGPT.exe, for example:

ChatGPT.exe.23960.dmp       2026-07-16 14:08:07   ~23.8 MB
ChatGPT.exe(1).23960.dmp    2026-07-16 14:24:57   ~24.0 MB
ChatGPT.exe(2).23960.dmp    2026-07-16 14:24:59   ~24.1 MB
ChatGPT.exe(3).23960.dmp    2026-07-16 14:25:29   ~24.1 MB

Post-update state

After Windows installed OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0 at about 20:26 local time, I restarted Windows and restarted the ChatGPT/Codex app multiple times. Running as administrator did not appear to be a useful mitigation.

As of a local baseline check at 2026-07-16 22:10:39 +08:00:

• Current installed version is 26.707.12708.0.
• ChatGPT.exe processes are running from the 26.707.12708.0 package path.
• No new matching Application Error / WER 0xc06d007f entries were found after the 20:26 update baseline.
• No new matching local ChatGPT.exe CrashDumps were found after that baseline.

The user-visible issue I am still trying to capture is a whole desktop-app exit during normal Codex use after the update/restarts. If it reproduces again, I will collect whether the newer 26.707.12708.0 build produces a fresh WER event, CrashDump, or Crashpad report.

Notes

• This does not look related to PowerShell 7. The confirmed crashes are ChatGPT.exe desktop-app crashes, not pwsh.exe crashes.
• I am not attaching .dmp files publicly because they may contain account/session/process-memory data. I can provide sanitized event details or share dumps privately if OpenAI maintainers have a secure channel.

the same problem‌

Thanks for all the feedback - we have address the issue https://github.com/openai/codex/issues/33375#issuecomment-4991172145.