When using Codex to generate or modify code across a large number of files, the entire application becomes extremely slow and laggy.
After Codex creates or edits many files within the same session, the UI responsiveness drops significantly. Simple actions such as scrolling, switching files, typing, or opening menus start to lag noticeably. In some cases, the editor becomes nearly unusable.
This issue seems to worsen as the number of files involved in the task increases. Once Codex has interacted with a large set of files in the project, the performance degradation becomes persistent until the application is restarted.
Expected behavior:
Codex should be able to handle multi-file code generation or modification tasks without causing severe UI lag or degrading the overall responsiveness of the application.
Actual behavior:
The application becomes extremely slow after Codex processes many files. UI interactions become delayed, typing lags, and the overall experience becomes frustrating and inefficient for development.
Steps to reproduce (example):
Open a medium-to-large project.
Use Codex to generate or modify code across many files.
Continue working in the same session for a while.
Observe that the editor gradually becomes very slow and unresponsive.
Additional notes:
Restarting the application temporarily resolves the issue, but the slowdown returns once Codex again processes a large number of files.
It sounds like you’re using a single session until the context window fills up, which then requires reoccurring compaction.
Have you considered starting a new chat session once the context reaches around 70% capacity? This can help you avoid wasting tokens on compaction, reduce the risk of losing information during summarization, and give you a clearer sense of what the new session already knows.
One useful practice when switching sessions regularly is to carry over only the necessary context. Keeping a local memory.md file for the project is a great way to record important information you don’t want to lose and can quickly reference in a new session.
The problem is that even after starting a new conversation, the application is still very laggy. It feels like some resources may not be properly released.
I suggest adding a mechanism so that the scrollbar does not need to load everything at once. Instead, users could click a “Load more” option to progressively load additional content, which may help alleviate this issue.
Lag during long AI sessions is not always caused by a single process. On my Windows system, it is common for an AI tool to leave one or more long-running processes active after they should have been terminated. When this happens, manually stopping those processes often restores normal system performance.
That said, the cause is not always related to the AI itself. Other background processes may also contribute to the slowdown. The practical approach is to use standard diagnostic methods—such as checking running processes and resource usage—to identify the root cause, whether it originates from the AI tool or from another application.
No, all of this comes from the Codex application itself. It is most likely related to Electron, so the layout and rendering within Electron may not be well optimized.
To be honest, I would suggest switching the Windows version of Codex to WinUI instead. That would significantly improve performance compared to using an HTML-based interface.
The lag is particularly noticeable when creating a new thread, where the application may freeze for approximately 3–8 seconds.