Codex Desktop App Becomes Unusable Due to `codex-tui.log` Being Used as State / Index

Resolved 💬 10 comments Opened Feb 9, 2026 by OlliberK Closed Feb 10, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.log to 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 codex processes 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_

View original on GitHub ↗

10 Comments

etraut-openai contributor · 5 months ago

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.log file 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.log file, 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.log file? Perhaps a malware checker or continuous backup program?

miraclebakelaser contributor · 5 months ago

Clearing codex-tui.log did nothing for me.

@etraut-openai I think these are part of same issue:
https://github.com/openai/codex/issues/11090
https://github.com/openai/codex/issues/11000

I posted a reproduction in https://github.com/openai/codex/issues/11000.

etraut-openai contributor · 5 months ago

@miraclebakelaser, those don't sound like the same issue.

OlliberK · 5 months ago

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:

When first opening the Codex App, there are no problems with starting new threads.
Once a chat completes, I will frequently be unable to continue that chat.

In some cases, I can send the message, but the app appears to be stuck on "thinking".
In other cases, when I enter a chat, the thread becomes essentially not responsive - I can't even copy the text I've sent, which remains in the dialogue box.

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 contributor · 5 months ago

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 .codex directory. 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 · 5 months ago

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 · 5 months ago

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:

Connecting to remote server: https://mcp.linear.app/mcp

Replacing ${LINEAR_API_TOKEN} ... Authorization

Server returned 401 after successful authentication

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 contributor · 5 months ago

Thanks, I feel better knowing that it's not a "same log line repeated" loop. Yeah, it's likely verbose MCP output.

lanpublications · 5 months ago

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 contributor · 5 months ago

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.