Long git diffs create lag in Codex App

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12861
• #12786
• #12937

Powered by Codex Action

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-server over stdio JSON-RPC:

• direct SQLite thread list: ~0.8–1.2 ms
• thread/list(limit=50): ~138–155 ms
• thread/read(includeTurns=false): ~6–13 ms
• thread/read(includeTurns=true): ~353–834 ms depending on thread size
• thread/resume: first call ~1660–1960 ms, then ~350–860 ms

The 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:

• big diffs are one trigger for lag
• there’s also a broader “large thread / thread resume / full history hydration” performance problem
• thread/list also seems slower than it needs to be for sidebar refreshes

Related reports that seem to be talking about the same family of issues:

• #14469
• #11011
• #11984

From my poking around, the two smallest promising fixes look like:

• make thread/list DB-first when SQLite is healthy
• avoid blocking thread selection on full thread/resume hydration

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.

Potentially related:

• https://github.com/openai/codex/issues/27570

---

Likely partially impacted by rust-v0.140.0: #27489 caches turn-diff rendering so repeated apply_patch updates no longer re-render the entire accumulated diff after every patch. #27031 also removes a duplicate rollout-history read during cold thread/resume.

• #27489
• #27031

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.