Repository navigation
sustained high CPU after launch/reopen (persists during use) + model picker broken #18463
Description
Sample of Codex app 2026422(current1.7gb, peek2.4gb) 6:18PM.txt
2026422night Sample of Codexapp(current2.53gb, peek5.1gb) 8:44 PM.txt
Sample of Codex Helper (Renderer)2026422.txt
Sample of Codex Helper (Renderer yeah not duoblcate really one more)2026422 .txt
seeing issue?
summary
- Launching Codex Desktop on macOS consistently causes two
codex helper renderspike and unable to set model. - non linearly larger ram usage overtime
gpt5.4 say to samples:
- main thread stuck in V8 snapshot restore path (repeated GetDataFromSnapshotOnce).
- affects both Codex Helper (Renderer) and main Codex process (see attached samples)
ElectronMain
→ v8::Context::FromSnapshot → v8::Isolate::GetDataFromSnapshotOnce (repeated) → ScriptStreamingTask::Run
apr 18:
- xhigh cpu: since open/reopen app, cpu usage about 120%(codex render)+120%(codex render)+50%(codex app). persist after a long use or not front most focus or kill render proc(restart still 120% to go).
- ui no respond: impossible switch model. click dropdown model list but can't set to. restart codex app lose every state then can set model again for a moment (during this high cpu all along)
- reproduces after clean launch without any user action
- main app bulk ram: root cause unsure.
timeline: apr 18 ~ apr 22 afternoon (codexapp proc normal at 0.5 ~ 0.6bg [screenshot below] or maybe somewhat detail im unobserved.) → apr 22 afternoon oom popup show codex app use 29gb (but that time im also viewing the Activity Monitor, i didnot notice the codex part ram to much, or say i notice it just a boring 500~600g the codex app and 400 to 500 for both render proc as i record. im very rememberable, becuz i saw the 29gb usage but activity monitor largely disagreed, where it comefrom[that time im finding was it child proc] then after a moment mac lag then freeze then restart ) → apr 22 6:18pm 1.7gb(this is the time i make first sample for trace cpu, i guess i have saw the ram too but looks like im clam, if i saw 1.7gb i should have bigger react) → 8:30pm 3.55gb(first react point) → 8:44pm 2.53gb → 9:38 PM 3.22gb
apr 25(ver)
- so back.
The sample shows main Electron/V8/Node loop repeatedly doing:
uv_run
-> uv__io_poll
-> LibuvStreamWrap::OnUvRead
-> StreamBase::CallJSOnreadMethod
-> V8 Function::Call
-> unknown JS/JIT frames
So likely cause: some stream/socket/IPC/log loop keeps feeding JS work. Not mainly UI rendering. Current memory in this sample is 297.6 MB, peak was 1.7 GB.
apr 23 entire day (same ver to apr 22, 26.417.41555 (1858))
- today have no sustained cpu. cpu clam and normal. tho
codexthe main app proc ram was well 1.6gb+ all the time. also saw lot node proc 500mb to 300mb one by one point to parent codex app proc.
apr 22 afternoon(26.417.41555 (1858), same ver to apr 22 morning):
- same to apr 18.
- and codex app use more ram than i tho, about 29gb before my mac crash restart becuz ram.
apr 22 morning (ver 26.417.41555 (1858)):
- apparently cpu back to normal. still can't set model
apr 21(ver 26.417.40842 (1851)):
- same to apr 18.
apr 19, afternoon(ver 26.415.40636 (1799)):
- occasionally dont begin when open/reopen, and stay that normal for a long moment, switch model work fine too in that moment.
reproduce step?
update to that Apr 18, 2026 or current newest version codex app, then just open it.
expected behavior?
prior version performance is still not bad like this, or a normal electron app cpu usage
Codex App ver?
26.415.32059 (1789)
subs u have?
pro
ur computer platform?
Darwin 25.4.0 arm64 arm
Additional info
plz oss codex app. oss is the sw backbone in ai era, extendability and stability foreveryone. not just who im observed and waiting and explain to a level openai want to fix all this overhead why not just who countering they know well they fix and therefor all us is imperfect so, let the right one to do it, its effortless. if really want to make good sw not just control a bad sw.
apr 22 night(8:30:10 PM, shout out to Raycast. clipHistory also records the detailed timing):
first time observed high RAM usage. or technically second if no screenshot oom that 29gb count
(the ... raw is cpu. yeah macos should oss too, so many thing need to fix.)
apr 18:
Activity
github-actions commentedon Apr 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
feisha20 commentedon Apr 19, 2026
Why has such a serious issue occurred, and why doesn't the official team provide downloads for previous versions???
negentropi commentedon Apr 19, 2026
@feisha20 too many control and if this oss, already fix in dayone or now im working on fixing that. so they should oss codex app.
feisha20 commentedon Apr 19, 2026
It's terrible. They should provide downloads for several previous versions until the new version is free of major issues.
feisha20 commentedon Apr 19, 2026
@fcoury It's terrible. They should provide downloads for several previous versions until the new version is free of major issues.
sxxov commentedon Apr 19, 2026
for more context it's "Codex Helper (Renderer)", & it spawns twice on startup, pegs at 100%+, & persists even when the window is hidden (closed but threads are running)
funnily enough, if we open the popup window, another "Codex Helper (Renderer)" process spawns & pegs to 100%
killing the process just brings it back up, & the only way to stop it, is to quit all of codex.
[-]unusaul cpu usage[/-][+][critical performance issue] unusaul high cpu usage forever [/+][-][critical performance issue] unusaul high cpu usage forever [/-][+][critical perf] unusaul high cpu usage forever [/+][-][critical perf] unusaul high cpu usage forever [/-][+][critical perf] unusaul high cpu usage forever by just open app[/+][-][critical perf] unusaul high cpu usage forever by just open app[/-][+][critical] unusaul high cpu usage forever by just open app[/+][-][critical] unusaul high cpu usage forever by just open app[/-][+][critical] xhigh cpu usage forever by just open app[/+][-][critical] xhigh cpu usage forever by just open app[/-][+][critical] xhigh cpu usage forever by just open/reopen app[/+][-][critical] xhigh cpu usage forever by just open/reopen app[/-][+][critical] xhigh cpu usage forever by just open/reopen app forever[/+][-][critical] xhigh cpu usage forever by just open/reopen app forever[/-][+][critical] xhigh cpu usage forever by just open/reopen app forever. codex app[/+]hacksurvivor commentedon Apr 21, 2026
This issue disappeared for a couple of days on my side, but it has now come back again on April 21, 2026.
Fresh data from today:
26.417.41555Darwin 25.5.0 arm64Codex Helper (Renderer)processes pinned above 100% CPU.From Activity Monitor today:
Codex Helper (Renderer)PID91385at115.1%CPU,18threads, CPU time15:37.88Codex Helper (Renderer)PID91156at113.8%CPU,18threads, CPU time15:36.74So the problem was gone briefly, then reappeared without me intentionally changing anything to fix or re-trigger it.
I also checked fresh logs under
~/Library/Logs/com.openai.codex/2026/04/21/and the same error family is still present today:Representative timestamps from today include:
2026-04-21T13:28:01Z2026-04-21T13:32:51Z2026-04-21T15:17:46ZAcross today's rotated log files on my machine, I currently count about
389,382matches for that samestable-metadata/Not a git repositoryerror pattern.Please treat this as an ongoing recurrence of the same bug rather than a one-off spike. The key point is:
If useful, I can follow up with a compressed log bundle or another Activity Monitor capture from the current recurrence.
negentropi commentedon Apr 22, 2026
@hacksurvivor
apr 22 morning:
wow that got even cooler is now im just run on 26.417.41555 (1858) but it kind of chill for now.
hmm...
[-][critical] xhigh cpu usage forever by just open/reopen app forever. codex app[/-][+]sustained high CPU after launch/reopen (persists during use) + model picker broken[/+]