Long git diffs create lag in Codex App

[jmoran650]

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?

1. Have a huge git diff build up in a thread.

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• App (Codex.Renderer process) crashes with CPU overload #12861
• Diff shows an excessive amount of change vs master #12786
• Prompt text box becomes extremely laggy when chat displays any rich UI elements #12937

Powered by Codex Action

[Fuiste]

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