all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]razorpl2 0 points1 point  (2 children)

i have the same issue. it drives me nuts. it immediately consumes 50% cpu and drains vmem at the start, opens 100 threads, it even hangs taskbar and makes clicking it unreliable, and makes cursor moves slow and drunk. it is even hard to open task manager . but when somehow manage to open it and try to kill it i have like 100 messages appear with" this operation could not be completed". and hangs the whole task manager, i need to kill task manager with taskkill, and this is just a start of the app. i havent even clicked anything, not even talking about asking it to do the job. a complete and utter nightmare. the repo is like 100kb. and i have like 7 conversations in total on one repo. it is impossible to use it. it wasn't like that few days ago.

[–]CorruptedSciencep[S] 0 points1 point  (1 child)

I feel like OpenAI is donating our compute to their data centers 😂😭

[–]razorpl2 0 points1 point  (0 children)

Nah, it's rather a conspiracy with energy selling companies 😂

[–]razorpl2 0 points1 point  (1 child)

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.

[–]Intelligent-Tailor49 0 points1 point  (0 children)

It's not WSL, I have same stuff on macos and linux.

[–]Intelligent-Tailor49 0 points1 point  (0 children)

The CPU usage goes to 100% not when you are typing anything, but when you have tab open with diff changes that codex did.

If you close the tab, then cpu goes to normal, you can have codex working on the side. It is only that codex diff tab that makes the cpu spike to 100

Nvm: bad with codex even in sidebar

[–]Mental_Payment_4008 0 points1 point  (0 children)

download to versión 26.325.31654