Repository navigation
Codex Desktop App Becomes Unusable Due to codex-tui.log Being Used as State / Index #11136
Closed as not planned
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 260208.1016 (571)
What subscription do you have?
PRO
What issue are you seeing?
After updating to Codex Desktop App version 260208.1016 (571), the application became increasingly slow and eventually unusable: threads would not open, UI actions silently failed, and responsiveness degraded severely.
Investigation revealed that the file codex-tui.log (a CLI/TUI log file) had grown to ~3.19 GB of plain text. The desktop app appears to read and rely on this log file to reconstruct or index thread/session state, rather than treating it as diagnostic-only.
This creates a catastrophic failure mode:
- Large log → UI hangs / threads cannot open
- Missing log → recent threads disappear entirely, although 3mo threads are available.
- Small replacement log → app becomes fast again
Replacing the large log with a small file of the same name immediately restored full UI responsiveness, strongly demonstrating causal linkage.
What steps can reproduce the bug?
- Use Codex Desktop App + Codex CLI over time
- Allow
codex-tui.logto grow large (in this case, ~3.19 GB) - Launch Codex Desktop App
- Attempt to open recent threads
What is the expected behavior?
- Threads cannot be opened (clicking does nothing)
- UI appears responsive, but actions silently fail
- App may spin indefinitely even for trivial actions
- Multiple
codexprocesses running, but no crash - Performance degrades over time
- Restarting the app or macOS only provides temporary relief
- Recent threads disappear when the log is missing
- Performance may correlate with system demands from other processes
Additional information
No response
Activity
etraut-openai commentedon Feb 9, 2026
Thanks for the bug report. It's an interesting theory, but I don't think it holds up. I'm not aware of any place where the app directly accesses the log file. I just asked Codex to do a thorough review of the app sources, and it confirmed this.
I've also reviewed the CLI (rust) code base, and I've confirmed that the
codex-tui.logfile is opened in "append only" mode, so its full contents are not read.A log file of 3.19GB is very large. It's more typical for it to be 10's (or at most 100's) of MB, not GB's. So that's a possible red flag.
I tried to replicate the performance issue by synthesizing a very large
codex-tui.logfile, and I didn't observe any performance degradation.Is it possible that you have some other code running on your system that's reading the
codex-tui.logfile? Perhaps a malware checker or continuous backup program?miraclebakelaser commentedon Feb 9, 2026
Clearing
codex-tui.logdid nothing for me.@etraut-openai I think these are part of same issue:
#11090
#11000
I posted a reproduction in #11000.
etraut-openai commentedon Feb 9, 2026
@miraclebakelaser, those don't sound like the same issue.
OlliberK commentedon Feb 10, 2026
Apologies for the late follow-up. You are correct: removing the log file did not improve performance. As an attempt to resolve the issues, I removed the .codex directory entirely and reinstalled the Codex app. Unfortunately, this does not appear to have resolved the issues.
To be more precise, what's happening now is:
Restarting the app works. Occasionally, I find that a "thinking" thread has completed its response; it just didn't return it to the UI.
After using the app for a while, (2) will happen again.
Additional context: I did not have any of these issues until the most recent updates. I hope you can get this resolved - this app is superb.
etraut-openai commentedon Feb 10, 2026
Thanks for the update. Do you have any non-default settings configured in your config file? In particular, do you have the
collab(subagents) experimental feature flag enabled? We have some reports of this resulting in behaviors like you're describing.You mentioned that you had a log file that was 3.19GB in size. I'd like to revisit that because it sounds very suspicious if that's the case. I'm guessing that you may have already deleted the old log file when you removed your
.codexdirectory. If you happen to still have it around (maybe kicking around in your trash?), could you peek into it and let me know if you see anything suspicious like a large number of repeated log lines?OlliberK commentedon Feb 10, 2026
You're welcome. Here's the features section -
[features]
unified_exec = true
shell_snapshot = true
collaboration_modes = true
apps = true
personality = true
shell_tool = true
I'll take a look at the log file now.
OlliberK commentedon Feb 10, 2026
I ran streaming analysis on the 3.19GB codex-tui.log (couldn’t open it directly). I don’t see evidence of a tight “same log line repeated” loop: in a filtered set of timestamped INFO/WARN/ERROR lines from the last 500k lines, the highest repeat count is 2.
However, the same slice shows verbose MCP stderr output from a HubSpot MCP server attempting to connect to Linear MCP and failing with StreamableHTTPError: Server returned 401 after successful authentication (including stack traces). Example lines:
My suspicion is that repeated MCP restarts/reconnect attempts could generate very large logs without identical-line repetition (timestamps/stack traces vary). Happy to provide more excerpts if useful.
As regards the overall log size, well, I do use Codex a lot!
etraut-openai commentedon Feb 10, 2026
Thanks, I feel better knowing that it's not a "same log line repeated" loop. Yeah, it's likely verbose MCP output.
lanpublications commentedon Feb 10, 2026
I'm experiencing the same exact thing, also with a custom config file and I noticed that I had 4 individual GIT processes running at 90% CPU utilization when this occurred.
etraut-openai commentedon Feb 10, 2026
I'm going to close and lock this thread because the title is misleading, and we've ruled out that behavior. If you're seeing high CPU utilization, we are tracking that in several other active bug reports.