codex-tui.log

Open 💬 6 comments Opened Mar 4, 2026 by danielheringers
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.107.0

What subscription do you have?

PRO

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Windows

What terminal emulator and version are you using (if applicable)?

PowerShell 7

What issue are you seeing?

I’m not sure if this is actually a bug, but I wanted to bring it to your attention. The codex-tui.log file is extremely large. Mine is around 50 GB. I’m not sure exactly what this file contains, but I thought it might be worth mentioning.

<img width="921" height="251" alt="Image" src="https://github.com/user-attachments/assets/d61562ad-5b0b-4ee6-a33b-4b6f3dd12fc9" />

What steps can reproduce the bug?

Go to C:\Users\YOU_USER\\.codex\log

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

6 Comments

etraut-openai contributor · 4 months ago

It's not typical for it to be that large, but there are situations where it can after significant usage.

You can manually delete it if you'd like.

allinaivideo · 2 months ago

almost same issue:

/goal long-running loop produces 480 KB single log lines via chain-nested turn{} tracing spans (34 GB log in one day)

Codex 0.130.0, model gpt-5.5 — same version as yours
codex-tui.log grew to ~34 GB in one day (yours ~33 GB in ~14 hours)
Cause according to reporter: chain-nested turn{otel.name="session_task.turn"} spans
Lines up to ~480 KB with hundreds of nested turns per line
Duplicate codex.turn.token_usage.* fields at every level
Status: open, labels bug, CLI, performance
Your analysis (millions of session_task.turn, duplicate token fields, long-running codex resume) matches this almost 1-to-1.

Devil-SX · 2 months ago

Same issue here. 52GB tui log

Arcnor · 1 month ago

I'm having this same problem, ~25GB in a single /goal session of a few hours. This is probably destroying my SSD for no good reason, can we have a way to just disable whatever is going into this file?

etraut-openai contributor · 1 month ago

Reopening the issue. We're working on a change that will make the TUI log optional and off by default. The most critical logs are already logged to a sqlite db and rotated, so the TUI log is largely redundant at this point.

amp42 · 1 month ago

@fcoury-oai was talking about this in a Twitter thread. Suggested debug route: feed this prompt into a CLI session:

Do a read-only investigation of codex-tui.log. Do not delete, truncate, rotate, or modify anything. Produce a report I can send to someone else with:
1. exact file size, modified time, and whether it is actively growing 2. the first and last timestamps visible in the log, if any 3. top repeated error/warning/message patterns 4. the last 200 relevant lines with secrets, tokens, API keys, user prompts, and personal paths redacted 5. any obvious runaway loop or repeated subsystem 6. the exact commands you ran
Do not include the full log. Save the report as codex-log-triage.txt on the Desktop.

My ~/.codex/log/codex-tui.log is 826 MB.

Analysis by GPT-5.5 after looking at generated codex-log-triage.txt:

The dominant repeated pattern is

warnings inside session_loop during turn processing. The recent tail repeatedly shows:

  codex_core_skills::loader: ignoring interface.icon_small/icon_large: icon path must not contain '..'

  That means Codex is repeatedly loading skill/plugin metadata and complaining about bad icon paths. Think:
  every time the app checks its toolbox, it says “this icon path is invalid,” then writes that complaint again
  and again.

  There is also a repeated MCP-related warning:

  Failed to refresh tools for MCP server 'codex_apps', using startup snapshot

  That suggests the Codex Apps MCP tool refresh is repeatedly failing and falling back to cached startup
  tools. That is worth reporting because it is a repeated subsystem failure and likely contributes to log
  growth.