Repository navigation
Long git diffs create lag in Codex App #13809
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.305.950 (863)
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.2.0 arm64 arm
What issue are you seeing?
If a thread has a huge git diff staged it causes the app to become extremely laggy. I at one point had +200,000 showing in the toggle git diff panel button and it caused the app to use a huge amount of memory and become extremely slow. Lag remains whether the thread with the huge diff is open or not. Committing changes and pushing fixed the lag.
What steps can reproduce the bug?
- Have a huge git diff build up in a thread.
What is the expected behavior?
No response
Additional information
No response
Activity
[-]Long git diffs create lag[/-][+]Long git diffs create lag in Codex App[/+]github-actions commentedon Mar 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Fuiste commentedon Apr 14, 2026
Adding data from #14469, since it was marked duplicate here.
I think, “large diff makes the app laggy” is real, and some investigation points to there being more going on. I did a local pass on latest
main(b3ae531b) and found a separate app-server cost on thread switching / thread hydration that’s big enough to cause visible freezes on its own.What I measured locally against the checked-out
codex-app-serverover stdio JSON-RPC:~0.8–1.2 msthread/list(limit=50):~138–155 msthread/read(includeTurns=false):~6–13 msthread/read(includeTurns=true):~353–834 msdepending on thread sizethread/resume: first call~1660–1960 ms, then~350–860 msThe interesting split is that the cheap metadata path is fast, but full transcript hydration is not. That lines up pretty well with the app-server paths in latest
main, and also with the production timings already captured in #14469.My current thoughts are:
thread/listalso seems slower than it needs to be for sidebar refreshesRelated reports that seem to be talking about the same family of issues:
From my poking around, the two smallest promising fixes look like:
thread/listDB-first when SQLite is healthythread/resumehydrationoxysoft commentedon May 9, 2026
Related CLI TUI root cause analysis: #21945 — the Rust TUI transcript overlay has the same O(n) rebuild problem. Large diffs would compound this since each diff cell gets full markdown re-parse + syntax highlighting on every overlay open, resize, and cell insertion. No virtualization or render caching anywhere in the pipeline.
0xdevalias commentedon Jun 17, 2026
Potentially related:
review-summaryspawns thousands ofgit hash-objectprocesses when nested repositories are present #27570Likely partially impacted by
rust-v0.140.0: #27489 caches turn-diff rendering so repeatedapply_patchupdates no longer re-render the entire accumulated diff after every patch. #27031 also removes a duplicate rollout-history read during coldthread/resume.That should reduce some lag in long sessions with large accumulated diffs, especially when many patches touch the same set of files. It probably does not fix the UI cost of actually displaying a huge diff, or bugs that produce an incorrect huge diff in the first place. Worth retesting on 0.140+ and keeping this open if large-diff display/review remains laggy.