Codex Desktop on macOS flickers generated text while response is in progress
Open 💬 7 comments Opened May 15, 2026 by jvyhm6w5cv-max
Codex Desktop on macOS flickers generated text while a response is in progress
Summary
Codex Desktop on macOS constantly flickers the generated assistant text while a response is still in progress. The text appears to visually refresh/re-render during streaming, which makes the app uncomfortable and annoying to use. The issue is visible during active generation and is not just normal model latency.
Environment
- App: Codex Desktop for macOS
- Codex app version:
26.513.20950 - App build:
2816 - Codex CLI version:
0.131.0-alpha.9 - macOS:
26.4.1(25E253) - Architecture:
arm64 - Hardware: MacBook Air
Mac17,3, Apple M5, 10-core CPU, 24 GB RAM - Sensitive identifiers such as serial number, hardware UUID, and local username omitted.
What is happening
- While Codex is generating an answer, the generated text flickers repeatedly.
- This happens during the in-progress streaming state.
- The behavior is visually distracting and makes longer runs harder to read.
- I saw another GitHub report/post mentioning similar flickering behavior, so this may not be isolated to my machine.
Expected behavior
The generated text should stream/update smoothly without repeatedly flickering or visually re-rendering the whole text area.
Actual behavior
The generated text area visibly flickers while the response is still in progress.
Reproduction steps
- Open Codex Desktop on macOS.
- Start or continue a local workspace conversation.
- Send a prompt that produces a multi-paragraph response or a longer in-progress generation.
- Watch the generated assistant text while it is streaming.
- Observe repeated flickering/re-rendering of the generated text while the run is in progress.
Notes
- This seems like a desktop UI rendering/streaming issue rather than a model-quality issue.
- I can provide a screen recording if maintainers need one.
- I have not yet isolated whether this depends on long sessions, generated assets, specific models, or a particular workspace.
7 Comments
This is happening for me too.
For me, Codex Desktop runs smoothly until the window is resized large enough. It runs fine on the built-in MacBook display, for example, but starts flickering when maximized on an external 4K display.
I experienced the same issue. My laptop is MacBook Pro 14-inch, M3. Codex Desktop works fine in the MacBook screen. But it start flickering on the 4k display.
I tried with another MacBook Pro 16-inch and the same 4k screen. Not any flickering on either display this time.
Looks like the flickering happens only when the 'pinned summary' is toggled on.
This may be the same underlying Desktop rendering/layout bug as #23245.
I added a more specific reproduction there: https://github.com/openai/codex/issues/23245#issuecomment-4490769572
Additional signal from my recording:
26.513.31313(2867) on macOS/Darwin24.6.0 arm64That workaround makes it look tied to Desktop layout/reflow or content-pane width, which seems related to the larger-window / external-display reports above.
Screen recording from my repro showing the transcript shake and the right-sidebar workaround:
https://github.com/user-attachments/assets/34bc9ce7-21b1-40bf-8466-15849258b3ed
I can reproduce this issue on a significantly newer Codex Desktop build.
Environment
26.616.51431(4212)0.142.0-alpha.626.5.1(25F80)Mac16,122560 × 1664); no external displayBehavior
Generated assistant text visibly flickers throughout active streaming. Previously rendered text appears to be repeatedly re-rasterized or repainted rather than only appending the newest tokens.
The issue persists after:
There are no Renderer/GPU crashes or Crashpad reports.
During streaming I observed:
12–23%CPU6–10%CPU, with an earlier spike near40%460 MBto473 MBwithin six secondsThis looks like a streaming layout/paint invalidation or compositor regression rather than a model/network issue. It may be related to per-token Markdown re-layout, scroll anchoring, or text-layer rasterization.
The bug remains reproducible in
26.616.51431, so it does not appear to be fixed by the newer Chromium/app build.