sustained high CPU after launch/reopen (persists during use) + model picker broken

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 render spike 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.

<img width="650" height="85" alt="Image" src="https://github.com/user-attachments/assets/c5c8d600-9efe-4a45-9750-91bcb9da10a6" />

Sample of Codex2026.04.25.txt

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 codex the 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.)
<img width="343" height="134" alt="Image" src="https://github.com/user-attachments/assets/8b6130ce-54eb-4d89-96d1-5735349da978" />

apr 18:
<img width="1057" height="136" alt="Image" src="https://github.com/user-attachments/assets/c245f0aa-1a67-4d85-b40d-4966e051a8a9" />