Windows Codex Desktop appears to reinstall/start SysmonDrv v13.22; WinDbg points to SysmonDrv.sys BSODs

Additional impact update from the affected user:

After further mitigation attempts, the machine rebooted/crashed again while Codex was being used for mitigation. The user reports that Codex-related crashes/reboots have now happened many times and caused loss of unsaved work/data.

The user has now switched Codex from Windows-native execution to WSL and restarted, as a temporary workaround. They still need an official answer on:

1. whether Codex Windows native intentionally installs/starts Sysmon/SysmonDrv,
2. how to fully disable that component,
3. whether Windows-native execution can be made safe without SysmonDrv,
4. what private logs/dumps OpenAI wants for diagnosis,
5. whether affected users can receive usage/token/subscription compensation for repeated BSODs and lost work.

Please treat this as more than a normal app crash: the suspected failure path involves a kernel driver (SysmonDrv.sys) and repeated full-system restarts.

3 things I suggest

1. (I believe codex-cli or codex-ide should work in ur case) If this works -- and reply back -- so it better can be root-caused back to the codex-desktop(a bit [trickey to debug because ur systeming is crashing])
2. modern windows installation (as much as I dont like to suggest it -- SysmonDrv is a windows thing or a Visual Studio / c++ related thing ? if you are developing )

2.1 sidenote with windows-11 - it has to do with the microsoft score (unrelated because you are using an very outdated version of SysmonDrv ---- this has importance -- because of the way CODEX DESKTOP is built and also intalled from the MICROSIOFT STORE ) https://learn.microsoft.com/en-us/sysinternals/downloads/microsoft-store

1. If your system is overclocked its completely natrual for the system to maybe crash - if your cpu spikes to 100% all the sudden --- you may argue -- you can still play games without crashing - but I will argue back that games dont usally take 100% of your cpu [I suggest undo all of the overclocking you did] (Wether its settings in the mothersboard-bios or some weird AMD supplied software for overclocking ) (a. go to your motherboard bios [click default settings] b. undo the overclocking and uninstall the AMD software , altenratively updating your motherboard bios should also help [if you bought a good brand - there is always a bios update every 2-4 months which is very good] [but i dont think you are in the lucky side if your are using some unknown brand -- because if you cpu is very modern and the motherboard is outdated weird things can happen because for how long AMD tries to maintained their AM4 sockets -- like off-labled/generic chinese motherboarids ] [that being said if its motherboard you could be using some of the])

I never would have guess, too see the day that linux would have the best hardware support. (but understand its a big deal for hardware people to say for themselves they helped improve the linux kernel -- and the different ways it complie for different systems too btw - what windows-embeded would never could have been --- historically speaking of/ )
but you do mention you do overclock yoursystem ---- when you play video games, and maximize your CPU does it crash?

If codex is the issue, the same should be replicated if you use Codex-cli or codex-ide
but I recomend give it a try, I think using IDE or CLI can fix the issue you are facing --- If Codex Desktop attached to SysmonDrv.sys and
crashes some how ---
your side report back if its the CODEX DESKTOP to use codex on other platforms (the ide extension is really good)
cant ask you for logs - because you say your system fully crashing

i be honest i you can also say , (I used another llm product to run WinDbg, and I didnt had the crash) in theory you could say that too , so maybe there is something with CODEX DESKTOP

https://developers.openai.com/codex/ide
(can be used inside your VSCODE editor)
or
https://developers.openai.com/codex/cli
----

just to confirm you are not using windows 8 or 8.1 or 7 or something else weird --- we are speaking about windows 10 or 11 (because drivers support can be a bit weird)
(perhaps a "windows server" version )

granted you may have a valid point when it does try to speak to Sysinternals Sysmon

far as I concern maybe WnDbg couldnt deal some some weird logs --- leading the ai model you used to confuse Sysmon which vary based on what prompt you used
(you can use //Sysinternals Suite//)
----
sysmon is now at version Sysmon v15.2
see - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

(but maybe its [Windows 10 kernel framework] ) so its not a click on the windows update thing (or blame your AMD drivers) Its a bit weird considering how much I like to credit AMD for how much they improved (if its a hardware issue )

Im not going to tell to try and manual start placing Sysmon v15.2 in the place you put it
also suspect are doing development work maybe with Visual Studio Enterprise or something that made you install WinDbg (because I noticed LLM models like to see whats installed on your ocmputer)

Thanks for the suggestions. A few clarifications from the affected machine:

1. This does not currently look like a generic CPU/RAM/overclock instability issue.

Overclocking is a reasonable general thing to check, but the crash evidence does not match a typical unstable CPU/RAM pattern. Multiple kernel dumps showed different bugchecks (0x50, 0x13A, 0xC2), but they repeatedly converged on the same module:

• MODULE_NAME: SysmonDrv
• IMAGE_NAME: SysmonDrv.sys
• stacks such as nt!ExFreePoolWithTag -> SysmonDrv+...

If this were primarily unstable CPU/RAM/overclocking, I would expect more random failing modules or WHEA/Machine Check evidence. The consistent kernel module attribution is why this issue is focused on SysmonDrv.sys and Codex Desktop Windows-native execution.

1. The Sysmon v13.22 instance does not appear to be my own pre-existing system/Visual Studio component.

I force-uninstalled Sysmon with C:\Windows\sysmon.exe -u force and confirmed both Sysmon and SysmonDrv were not installed (sc.exe query returned 1060). After reboot, before using Codex, SysmonDrv was still absent. After resuming Codex Desktop / Windows-native local execution, Sysmon and SysmonDrv appeared again and were running.

That timing is the important part: the old SysmonDrv.sys reappeared after Codex Desktop interaction, not because it was simply sitting on the machine from Visual Studio, WinDbg, or my normal Windows installation.

1. I agree that trying Codex CLI / IDE / WSL is useful as isolation.

I have already switched Codex Desktop away from Windows-native execution to WSL as a temporary mitigation. If the machine remains stable under WSL/CLI/IDE while Windows-native Codex Desktop reintroduces SysmonDrv, that would further narrow the issue to Codex Desktop's Windows-native execution path.

1. The version question is still relevant, but not as a user-side fix.

Microsoft Sysmon is currently much newer than v13.22, but manually updating Sysmon is not a proper mitigation if Codex Desktop is the component reinstalling or starting an older driver. The thing I need from maintainers is confirmation of whether Codex Desktop Windows-native mode intentionally installs/starts Sysmon/SysmonDrv, and if so, how to disable it or ensure it uses a safe/current component.

So I am not claiming overclocking can never crash a PC. I am saying the evidence from this incident points elsewhere: repeated crashes attributed by WinDbg to SysmonDrv.sys, plus a reproducible timeline where SysmonDrv returns after Codex Desktop Windows-native usage.

Additional hardware / OS stability context from the affected user:

This is not an old or unsupported Windows installation, and it is not an obscure/off-brand motherboard or BIOS environment. The system is kept on current Windows updates. The user also reports that this machine is normally stable outside of this Codex Desktop Windows-native/SysmonDrv incident.

I am intentionally not posting a full hardware fingerprint publicly here. Exact CPU/GPU/RAM/BIOS/Windows build information can be provided privately to OpenAI maintainers if needed.

The main point is that the current evidence does not support reducing this to a generic “bad BIOS / unstable overclock / outdated Windows” explanation. The reproducible timeline remains:

1. Sysmon / SysmonDrv force-uninstalled and confirmed absent (1060).
2. Reboot.
3. Before Codex Desktop Windows-native interaction, SysmonDrv remains absent.
4. After Codex Desktop Windows-native/local execution interaction, Sysmon / SysmonDrv reappear.
5. Subsequent crashes are attributed by WinDbg to SysmonDrv.sys.

So hardware/BIOS details can be shared privately, but the public root-cause signal remains the Codex Desktop Windows-native path reintroducing SysmonDrv.sys and the crash dumps repeatedly pointing to that driver.

Concrete hardware context from the affected user:

• Machine class: Razer 2025 14-inch laptop / Razer Blade 14-class system
• Memory: 64 GB
• Storage: 2 TB SSD
• GPU: NVIDIA GeForce RTX 5070 Laptop GPU configuration
• Windows: kept current with Windows updates

This is a modern OEM laptop configuration, not an unsupported old Windows installation, a generic/off-brand desktop motherboard, or an unusual BIOS environment. The user reports the system is normally stable outside of this Codex Desktop Windows-native / SysmonDrv.sys incident.

Exact BIOS build, Windows build, and driver package versions can still be provided privately if OpenAI maintainers need them, but the high-level hardware context should rule out the earlier suggestion that this is likely due to a generic/unknown motherboard or legacy platform issue.

driver package versions can still be provided privately if OpenAI maintainers

c. (fastest) use VS CODE STUDIO and the IDE extention https://developers.openai.com/codex/ide

1. if it doesnt work -> Update to windows 11, you hardware way too new , SysmonDrv 13.22 was a thing before windows 11 was even annouced - and vibe coded in a afternoon (yes i said it)
2. uninstall RazerAppEngine or update it (if its on the latest version , im sure you can uninstall it )

to yur maschine classed theres is bios updates from 3 days ago

<img width="1414" height="436" alt="Image" src="https://github.com/user-attachments/assets/cefcded2-4908-45c4-bf98-7df2f4f1d515" />

<img width="1152" height="751" alt="Image" src="https://github.com/user-attachments/assets/0405c39b-102f-4c4a-8846-d0b5b6f13ce8" />

Thanks @Mahkhmood9, appreciate the suggestions.

Current status update from the affected user: after switching Codex Desktop from Windows-native execution to WSL and restarting, the machine has not encountered the crash/reboot issue so far.

That is useful isolation data: WSL appears to be a working temporary workaround on this machine, while the crashes were observed on the Codex Desktop Windows-native/local execution path where Sysmon / SysmonDrv were reintroduced.

However, this still needs an official Codex fix or explanation. Windows-native Codex Desktop should not silently reinstall/start an old SysmonDrv.sys kernel driver after the user has force-uninstalled it, and it should not be possible for that path to repeatedly crash the host system. The WSL workaround helps the user keep working, but it does not resolve the underlying Windows-native/SysmonDrv issue.

Thanks @Mahkhmood9, appreciate the suggestions. Current status update from the affected user: after switching Codex Desktop from Windows-native execution to WSL and restarting, the machine has not encountered the crash/reboot issue so far. That is useful isolation data: WSL appears to be a working temporary workaround on this machine, while the crashes were observed on the Codex Desktop Windows-native/local execution path where Sysmon / SysmonDrv were reintroduced. However, this still needs an official Codex fix or explanation. Windows-native Codex Desktop should not silently reinstall/start an old SysmonDrv.sys kernel driver after the user has force-uninstalled it, and it should not be possible for that path to repeatedly crash the host system. The WSL workaround helps the user keep working, but it does not resolve the underlying Windows-native/SysmonDrv issue.

you cant try an text if you even got a temporary fix for your issue - whats happening with your issue is windows/hardware issue -- what do you expect them to do? its not like you provided actual logs and data to back its a codex desktop thing

instead you ignore any attempt for help - and dont provide anything practical - beside poorly written llm written argument

Thanks for continuing to help. I understand your point, and I do appreciate the suggestions.

One clarification first: I am a Chinese-speaking user, so I use an LLM to help translate and structure my replies in English. That is only to make the technical report clearer and less ambiguous. I am not trying to avoid providing logs or ignore practical troubleshooting suggestions.

My current understanding is not “Codex magically crashes the hardware by itself.” The issue appears more specific: Codex Desktop’s Windows-native/local execution path seems to reinstall or start an old SysmonDrv.sys after I start/resume a conversation. The final crash may be caused by a compatibility bug between that old Sysmon driver and my hardware/driver environment, but the important point is that the driver reappears after Codex Desktop Windows-native usage.

I did also investigate the overclocking angle. During troubleshooting, the AMD/Razer CPU overclocking-related driver/service was disabled/stopped, but the machine still rebooted/crashed afterward. So I do not currently have evidence that CPU overclocking is the primary cause.

Current mitigation result: after switching Codex Desktop from Windows-native execution to WSL and restarting, I have not encountered the crash/reboot issue again so far. That is useful isolation data, but it is still a workaround rather than a fix for the Windows-native path.

Here is the practical evidence summary collected so far:

WinDbg / crash dump summaries:

1) Bugcheck 0x50 PAGE_FAULT_IN_NONPAGED_AREA
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   FAILURE_BUCKET_ID: AV_SysmonDrv!unknown_function
   Stack included: SysmonDrv+1321

2) Bugcheck 0x13A KERNEL_MODE_HEAP_CORRUPTION
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   FAILURE_BUCKET_ID: 0x13a_12_SysmonDrv!unknown_function
   Stack included: nt!ExFreePoolWithTag -> SysmonDrv+821d

3) Bugcheck 0xC2 BAD_POOL_CALLER
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   FAILURE_BUCKET_ID: 0xc2_99_SysmonDrv!unknown_function
   Stack included: nt!ExFreePoolWithTag -> SysmonDrv+81fe

More recent dumps after Codex Desktop was used again:

4) Bugcheck 0xC2
   PROCESS_NAME: codex.exe
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   Stack included: nt!ExFreePoolWithTag -> SysmonDrv+...

5) Bugcheck 0x13A
   PROCESS_NAME: codex.exe
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys

6) Bugcheck 0xC2
   PROCESS_NAME: RazerAppEngine
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys

Sysmon / service timeline summary:

- `C:\Windows\sysmon.exe -u force` was run.
- `sc.exe query SysmonDrv` and `sc.exe query Sysmon` returned 1060 / service not installed.
- After reboot, before using Codex Desktop Windows-native execution, SysmonDrv was still absent.
- After resuming/using Codex Desktop Windows-native/local execution, both services reappeared and were running:

  SERVICE_NAME: SysmonDrv
  TYPE: KERNEL_DRIVER
  STATE: RUNNING

  SERVICE_NAME: Sysmon
  TYPE: WIN32_OWN_PROCESS
  STATE: RUNNING

- The observed Sysmon version was 13.22.
- The observed files were:
  C:\Windows\sysmon.exe
  C:\Windows\SysmonDrv.sys

Overclocking-related check:

- AMDRyzenMasterDriverV29 was checked during troubleshooting.
- It was observed as STOPPED, and later disabled/stopped during mitigation.
- Sysmon/SysmonDrv still reappeared and crashes still occurred afterward.

I can provide full minidumps, .evtx logs, and full WinDbg output privately to OpenAI maintainers if they request them. I do not want to publish full crash dumps publicly because they may contain machine/account-specific information.

I agree that CLI/IDE/WSL are useful isolation paths. I have not moved my main workflow to CLI because much of my current project management and non-coding work is inside the Codex Desktop App. So CLI/IDE can help isolate the issue, but they are not equivalent replacements for fixing the Codex Desktop Windows-native behavior.

Request for OpenAI maintainers:

The affected user is willing to provide the original Windows event logs, WinDbg outputs, and crash dump files privately to OpenAI for investigation.

Because full minidumps / MEMORY.DMP / .evtx files may contain machine-specific or account-specific data, we do not want to upload them publicly to this GitHub issue. Please provide an official private intake path or confirm the preferred channel for sending:

• original Windows System/Application event logs around the crash times,
• minidumps from C:\Windows\Minidump,
• relevant MEMORY.DMP analysis if needed,
• full WinDbg !analyze -v outputs,
• Service Control Manager events showing Sysmon / SysmonDrv installation/start times,
• sc.exe query before/after outputs,
• SysmonDrv.sys / sysmon.exe version and timestamp evidence,
• mitigation evidence after switching Codex Desktop from Windows-native execution to WSL.

Current high-level evidence already summarized in this issue:

1. Multiple bugchecks (0x50, 0x13A, 0xC2) repeatedly point to SysmonDrv.sys.
2. Sysmon / SysmonDrv were force-uninstalled and confirmed absent (1060).
3. After reboot they remained absent before Codex Desktop Windows-native usage.
4. After Codex Desktop Windows-native/local execution interaction they reappeared and were running.
5. The observed Sysmon version was 13.22, while the current Microsoft Sysmon release is much newer.
6. The AMD/Razer CPU overclocking-related driver/service was stopped/disabled during troubleshooting, but crashes still occurred afterward.
7. After switching Codex Desktop from Windows-native execution to WSL, the crash/reboot issue has not reappeared so far.

The user is requesting official investigation of whether Codex Desktop Windows-native mode intentionally installs/starts Sysmon/SysmonDrv, why this old driver version is involved, how to disable it, and whether affected users can receive usage/token/subscription compensation due to repeated full-system crashes and lost work.

Stack included: nt!ExFreePoolWithTag -> SysmonDrv+...

dont consume the two the CLI and IDE are two different products (the IDE aka means the VSCODE EXTENTION )
Do what I told you earlier ,

1. update your bios
2. go to your bios - and use default settings
3. go to the vibe coded AMD drivers app --- and try search for something call "reset settings"
4. if you can , Im sure reinstall with windows 11 would fix the issues due to the nature of how different its installed there

you earlier refused to give me your windows version , which is a bit funny to me ---

anyways - if you can please provide the crash dumps - im sure it can help the openai team to debug (or not?)

second the codex - ide within the visual studio isnt that bad - and honestly I think better --- not that you cant get simular exprience with either of them --- I mean the codex desktop consume , more cpu and is 1.5gb on the ssd (which I dont care but im not a fun of it)

You are not going to do it, because you expect a coding agent, to restart your computing and do it for you - and reset your bios settings, update it extra?

Im sure if you can afford your expensive laptop - you can afford 5 minutes to read something from someone who tries to help you

<img width="885" height="483" alt="Image" src="https://github.com/user-attachments/assets/17834766-2162-4e82-a38d-edf9b8d1648a" />

* The AMD/Razer CPU overclocking-related driver/service was stopped/disabled during troubleshooting, but crashes still occurred afterward.

doesnt matter, unless you dont reset your bios, some bios settings matter

1. it could be a faulty microsoft-windows installment /

you didnt even tell me if you are on windows 10 or widnows edition or windows china edition

Personally if you ask me I recomend you install Linux and never look back (I like fedora releases) -- because AMD tries ot best to be so awful at support windows - despite pioneers others things in the Semi conductor indurstry ---

https://docs.fedoraproject.org/en-US/quick-docs/switching-desktop-environments/
(next use switchdesk kde) and never look back at windows -- or use macos (but honestly no reason not to use linux nowadays --- just avoid archlinux)

Maybe one of my earlier replies was not clear enough, so let me clarify.

I was not refusing to provide my Windows version. When I said the system is always kept up to date, I meant that I am using Windows 11 and keeping Windows, BIOS, and drivers current. For clarity, the Windows information is:

Edition: Windows 11 Home Chinese Edition
Version: 25H2
Installed on: 2026-01-02
OS build: 26200.8655
Windows Feature Experience Pack: 1000.26100.315.0

I am also not too lazy to troubleshoot hardware compatibility. I have already spent a lot of time checking the hardware/driver angle. My point is that the Codex Desktop Windows-native / PowerShell sandbox path appears to keep reinstalling or starting an old SysmonDrv.sys version that conflicts with my hardware/driver environment. That is the behavior I need OpenAI/Codex maintainers to investigate.

Please also understand that not every professional workflow here is purely programming. I use Codex App for project management and a lot of non-coding professional work as well. For example, music production/composition workflows require Windows software, plugins, drivers, and local project context, so moving completely to a non-Windows environment is not realistic for me. That is also why I bought a high-memory laptop; I bought it before the RAM price increase, and it has been a very worthwhile investment for this kind of work.

So I do appreciate the suggestions about BIOS, drivers, CLI, IDE, and Linux, and I understand you are trying to help. But the issue I am reporting is still specifically about Codex Desktop’s Windows-native/PowerShell execution path bringing back SysmonDrv.sys after it was removed, followed by crashes where WinDbg points to that driver.

Maybe one of my earlier replies was not clear enough, so let me clarify. I was not refusing to provide my Windows version. When I said the system is always kept up to date, I meant that I am using Windows 11 and keeping Windows, BIOS, and drivers current. For clarity, the Windows information is: `` Edition: Windows 11 Home Chinese Edition Version: 25H2 Installed on: 2026-01-02 OS build: 26200.8655 Windows Feature Experience Pack: 1000.26100.315.0 ` I am also not too lazy to troubleshoot hardware compatibility. I have already spent a lot of time checking the hardware/driver angle. My point is that the Codex Desktop Windows-native / PowerShell sandbox path appears to keep reinstalling or starting an old SysmonDrv.sys version that conflicts with my hardware/driver environment. That is the behavior I need OpenAI/Codex maintainers to investigate. Please also understand that not every professional workflow here is purely programming. I use Codex App for project management and a lot of non-coding professional work as well. For example, music production/composition workflows require Windows software, plugins, drivers, and local project context, so moving completely to a non-Windows environment is not realistic for me. That is also why I bought a high-memory laptop; I bought it before the RAM price increase, and it has been a very worthwhile investment for this kind of work. So I do appreciate the suggestions about BIOS, drivers, CLI, IDE, and Linux, and I understand you are trying to help. But the issue I am reporting is still specifically about Codex Desktop’s Windows-native/PowerShell execution path bringing back SysmonDrv.sys` after it was removed, followed by crashes where WinDbg points to that driver.

my theory is , that there is bad drivers support with AMD with your WIndows Chinese Edition,, and razor is a oem manufactors that isnt
ddr5 honest does mean anything, and ddr4 is just as okay despite ddr5 being btter

maybe "razer-blade-14"/"razor" has really bad support with windows-chinese-edition (its well known some internals are a bit different in the chinese edition / but it could be 5 other products in a comob of Razor/Microsoft/Amd both having issues --- maybe its a bad OEM release you got of windows -- with the automatically installed windows versions anyhow im not a fan of it ) do be fair you are using codex, you just want to prevent some system crashes honestly if you can provide with the crash data --- maybe we can pin point if its Microsoft/Razor/Or AMD (which btw I dont like AMD)

you only need 16gb of ram a 5 year old laptop can do just as fine
--- but anyways

as per what you said - for music/or whatever I guess everything has a replacement - but I am not going to fight it - because we all got some software we all like

second you can try update your bios here (try to search on the back of your laptop )
if you are on

Edition: Windows 11 Home Chinese Edition (my guess/theory supplies you some how with a faulty drivers --- which )

maybe you can try move to
windows 11 ltsc/enterprise (windows home/pro [please dont use it])
(for atleast temporary fix the issue for you --- as its something weird - with windows internals or whatever ) (if it fixes its doesnt inherintly directs to Windows 11 Home china edition --- known to make issues --- and there is no reason you dont make the best of the hardware you bought )

but I get what you mean you are facing some issues with Codex Desktop - and you got the latest hardware

https://mysupport.razer.com/app/answers/detail/a_id/20634/~/razer-blade-14-%282025%29-bios-updater-%7C-rz09-0530x

but I assumed bios updating wont help you (but you can actually reset the bios --- because you say the crash happens after a while)

I assume you can use taobao to activate your other windows

1. if you can attach Crashlogs / Data dumps (which are purely for analysis reasons --- to see if there is a specific function that triggers it) and again I blame AMD for it -- but razor has likely a part in it
2. if you can try , reset bios (or update-bios in their website)
3. I recomend not using Windows 11 chinese Edition (considering Razor and Microsoft history with how they ship product there --- also dont forget ddr5 is still fairly new- maybe you are using some old driver and bugger driver) (consider using Windows Enterprise or Windows 11 Home non-chinese )

Update after further testing today:

I also updated the machine BIOS yesterday, so I have not been ignoring the hardware/BIOS troubleshooting path. However, the issue still came back.

The current pattern is still that whenever Codex Desktop uses the Windows-native / PowerShell execution path, it appears to bring back the old Sysmon component (SysmonDrv.sys / sysmon.exe version 13.22). That old driver version then appears to conflict with my hardware/driver environment and the machine crashes again.

This is extremely frustrating because I do not actually need Sysmon/SysmonDrv for my workflow. My expected workaround would be simple: disable that service/driver path and keep using Codex Desktop normally. But Codex Desktop currently does not provide a user-facing switch to disable this component, and it also does not appear to use an updated SysmonDrv version.

At this point, I do not think the core issue is that my laptop drivers are too old. The stronger signal is that Codex Desktop is using or reintroducing an old bundled SysmonDrv version. Codex should either update/remove that dependency, provide a supported way to disable it, or avoid reinstalling/starting it after the user has explicitly removed it. I should not have to downgrade or reshape a modern Windows laptop environment just to make Codex Desktop compatible with an old kernel driver it brings back.

New timing evidence from today:

Codex package currently observed:
OpenAI.Codex_26.623.13972.0
Install folder creation time: 2026-07-03 20:15:46

Sysmon/SysmonDrv reinstall events observed after that:
2026-07-03 23:21:42 - sysmon / SysmonDrv installed
2026-07-03 23:43:38 - sysmon / SysmonDrv installed
2026-07-03 23:53:41 - sysmon / SysmonDrv installed
2026-07-04 00:03:44 - sysmon / SysmonDrv installed

Observed Sysmon version:
13.22

Latest crashes after the issue returned:
2026-07-06 10:55 - Bugcheck 0xC2
2026-07-06 15:04 - Bugcheck 0x50

BIOS currently observed:
Razer BIOS 1.06
Release date shown by Windows: 2026-04-23

I had manually removed Sysmon/SysmonDrv again after reboot, which is why the service may not be visible at the moment of checking. The important part is the reinstall/start pattern and the crash timing around Codex Desktop Windows-native/PowerShell usage.

Update after further testing today: I also updated the machine BIOS yesterday, so I have not been ignoring the hardware/BIOS troubleshooting path. However, the issue still came back. The current pattern is still that whenever Codex Desktop uses the Windows-native / PowerShell execution path, it appears to bring back the old Sysmon component (SysmonDrv.sys / sysmon.exe version 13.22). That old driver version then appears to conflict with my hardware/driver environment and the machine crashes again. This is extremely frustrating because I do not actually need Sysmon/SysmonDrv for my workflow. My expected workaround would be simple: disable that service/driver path and keep using Codex Desktop normally. But Codex Desktop currently does not provide a user-facing switch to disable this component, and it also does not appear to use an updated SysmonDrv version. At this point, I do not think the core issue is that my laptop drivers are too old. The stronger signal is that Codex Desktop is using or reintroducing an old bundled SysmonDrv version. Codex should either update/remove that dependency, provide a supported way to disable it, or avoid reinstalling/starting it after the user has explicitly removed it. I should not have to downgrade or reshape a modern Windows laptop environment just to make Codex Desktop compatible with an old kernel driver it brings back. New timing evidence from today: `` Codex package currently observed: OpenAI.Codex_26.623.13972.0 Install folder creation time: 2026-07-03 20:15:46 Sysmon/SysmonDrv reinstall events observed after that: 2026-07-03 23:21:42 - sysmon / SysmonDrv installed 2026-07-03 23:43:38 - sysmon / SysmonDrv installed 2026-07-03 23:53:41 - sysmon / SysmonDrv installed 2026-07-04 00:03:44 - sysmon / SysmonDrv installed Observed Sysmon version: 13.22 Latest crashes after the issue returned: 2026-07-06 10:55 - Bugcheck 0xC2 2026-07-06 15:04 - Bugcheck 0x50 BIOS currently observed: Razer BIOS 1.06 Release date shown by Windows: 2026-04-23 `` I had manually removed Sysmon/SysmonDrv again after reboot, which is why the service may not be visible at the moment of checking. The important part is the reinstall/start pattern and the crash timing around Codex Desktop Windows-native/PowerShell usage.

I like to blame the issues on Windows Chinese edition --- I do recomend you try and someone Windows Enterprise LTSC

but if you want I also recomend return this product because its crashing - if you got a new computer that is randomally crashing -- which is unexplained

you argue its codex -- to which I dont know I

that said I told you over and over to go and update your bios

((I used translation from Korean to Chinese , [machine translation])
)如果你能提供崩溃日志/数据转储文件（纯粹是为了分析——看看是否有特定功能触发了问题），那就太好了。我再次强调，问题出在 AMD 身上——但 Razer 也可能脱不了干系。

如果可以，请尝试重置 BIOS（或者在其官网上更新 BIOS）。

我建议不要使用 Windows 11 Chinese Edition 中文版（考虑到 Razer 和微软在中文版产品发布方面的历史——而且别忘了 DDR5 内存仍然比较新——你可能正在使用一些过时的驱动程序，或者驱动程序本身存在问题）。（建议使用 Windows 企业版或 Windows 11 家庭版（非中文版）。

顺便说一句，你本来可以花不到700元人民币买一台五年前的笔记本电脑，配备GTX 2070显卡和32GB DDR4内存。

利用你的设备保修。

但话说回来——我还是觉得问题出在“Windows 11中文版”上。

<img width="1414" height="436" alt="Image" src="https://github.com/user-attachments/assets/e3781bd0-bb28-4529-a9b6-9a8212bf4b75" />

再说一遍，

我把问题归咎于你正在运行的 Windows 版本——

！！！

没有任何理由不这么做

！！！

没有理由，你应该使用…… (+ AMD CPU DRIVERS === 这个问题)

Windows 是罪魁祸首——从 Windows 中文版升级到 Windows 企业版

或者也可以通过安装正确的驱动程序来解决

我不相信 Razer 会支持 Windows 中文版，因为（由于“微软”提供的内部组件不同）

你的驱动程序版本已经 9 个月了（BIOS）。

其次，我认为你应该使用你的“设备保修”并退货——但我认为如果你没有使用“Windows 中文版”，而是使用“Windows 企业版 LTSC”或“Windows 家庭版”，这个问题是可以解决的。

@Cartmancxx
It could be an hardware issue
! ! !
use your service warrnty -
but I like it to be a DRIVER ISSUE, because it indurstry standard to support older hardware and not cause BSOD - in cirtical drivers ...

@Cartmancxx
这可能是硬件问题
！！！
利用你的保修服务吧——
但我更希望这是驱动程序的问题，因为支持旧硬件且不导致关键驱动程序引发蓝屏（BSOD）是行业标准做法。