[Linux][ChatGPT Desktop] Long conversations render completed responses extremely slowly while browser already shows full response

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.41651

What subscription do you have?

Plus

What platform is your computer?

Linux Mint 22.2, x86_64; Linux 6.17.0-35-generic x86_64 x86_64 Desktop session: X11

What issue are you seeing?

In ChatGPT Desktop for Linux, a long ChatGPT conversation can take many minutes to visually display/render an assistant response.

This does not appear to be model generation latency or network latency.

I tested the same conversation simultaneously in Brave. I asked the assistant to generate approximately 700 words and end the response with the exact text END-OF-RESPONSE.

The browser showed the entire completed response, including END-OF-RESPONSE, before the Linux desktop app had even started displaying the assistant response.

The desktop app then began progressively displaying the already-completed response very slowly.

A new/fresh ChatGPT conversation in the same desktop app responds and renders much more quickly, so the problem appears to be triggered by longer conversations.

While the affected conversation was slowly rendering a response, pidstat showed one ChatGPT renderer process using very high CPU. Over a 10-second sample:

ChatGPT renderer PID 1077659 averaged 82.85% CPU.
Individual samples reached approximately 130%, 132%, 163%, 119%, 105%, and 93% CPU.
The ChatGPT GPU process averaged approximately 13% CPU during the same test.
The system itself was not CPU-saturated.

The affected process was:

/usr/lib/chatgpt/ChatGPT --type=renderer ... --ozone-platform=x11 ...

This appears to be a client-side desktop rendering/update performance problem rather than slow response generation.

What steps can reproduce the bug?

Open ChatGPT Desktop on Linux.
Open a relatively long existing ChatGPT conversation.

Ask for a substantial response, for example:

Write about 700 words explaining how DNS works. Use several paragraphs. End the answer with the exact text: END-OF-RESPONSE

While the desktop app is waiting or slowly displaying the answer, open the same conversation on chatgpt.com in a browser.
Observe that the browser may already show the complete response, including END-OF-RESPONSE, while the Linux desktop app has not yet begun displaying it or is still slowly rendering it.

Monitor the desktop app with:

pidstat 1 -C ChatGPT

Observe high CPU usage in a ChatGPT --type=renderer process while the already-completed response is progressively rendered.
Repeat a similar prompt in a fresh/new conversation. The new conversation renders much faster.

The issue persists after completely terminating all ChatGPT processes and restarting the desktop application, so it is not simply caused by leaving the app running for a long time.

What is the expected behavior?

Once the server-side response is complete and synchronized, ChatGPT Desktop should display/stream the response at approximately normal UI speed.

A long conversation should not cause an already-completed response to take minutes to appear, nor should displaying ordinary text require sustained near-one-core or multi-core renderer CPU usage.

Performance should be reasonably comparable between a long existing conversation and a newly created conversation.

Additional information

This is specifically a rendering/display problem, not simply "slow responses."

The important A/B observation is:

Same account
Same conversation
Same computer/network
Browser already has the complete assistant response
Linux Desktop has not yet started displaying it, or is still displaying it extremely slowly

This makes server-side model generation unlikely to be the bottleneck.

Environment details:

Linux Mint 22.2
Kernel: Linux 6.17.0-35-generic
Architecture: x86_64
X11 (--ozone-platform=x11)
ChatGPT Desktop installed under /usr/lib/chatgpt/
Chromium/Electron-style renderer architecture
4 logical CPUs

Related issues may include desktop live-update/rendering problems such as openai/codex#32466, but I have not found an existing report documenting this exact Linux behavior where the browser has the fully completed response before Desktop even begins rendering it.

Start by reproducing the long-conversation comparison described in the report, then monitor /usr/lib/chatgpt/ChatGPT with pidstat 1 -C ChatGPT, focusing on the --type=renderer process under X11. Compare the desktop output with chatgpt.com and the fresh-conversation case; done means completed responses render promptly without sustained high renderer CPU usage.