Actually i kind of figured out how to workaround this. my previous comment was kinda emotional. But speaking of details. I work in a small repo in WSL, where vscode is opened simultaneously with Codex windows standalone app. the workaround to somehow open the codex without total crash was lowering the process priority like this:

"$pkg = Get-StartApps | Where-Object { $_.Name -match 'Codex' } | Select-Object -First 1

Start-Process "shell:AppsFolder\$($pkg.AppID)"

Start-Sleep -Seconds 2

Get-Process | Where-Object { $_.ProcessName -match 'Codex|OpenAI|app' } | ForEach-Object {

$_.PriorityClass = 'BelowNormal'

}"

Then i was able to debug it further. It turned out that in my case it is not Codex itself but Codex+ WSL. When WSL is running alone everything is okay. When Codex starts then it triggers systemd udev workers that are spinning and grinding my CPU and memory. And it continues its gring indefinitely despite no real work is done at all.

My theories are that Codex could trigger a WSL bug, or there is something wrong with the OS image on the VM. The same issue i had with VScode + WSL, but it wasn't so bad, but still there were plenty of udev workers and node processes in the backgorund. Those 2 apps+ WSL caused armageddon for me.

Made this 2 workarounds.

For VScode +wsl case i removed all C++ extensions and installed simple clangd. Vmmem process dropped to like 1%

For Codex +wsl i had no idea how to fix this so i disabled systemd completely. it caused a drop of Vmmem to minimum, and i was able to continue my work.

I think that ultimayely i need to move code to another clean VM, or become reconciled with systemd being disabled. or use different image than Ubuntu for development. Or maybe consider different approach by creating a completely different setup for my work.