Codex tui logs keeps growing and not getting rotated

Thanks for the bug report.

Why do you think this is slowing down the CLI? It's simply appending to the end of the log file.

+1 in my case it has grown to over 120GB in the course of just a few days.
I'm on windows.

<img width="341" height="84" alt="Image" src="https://github.com/user-attachments/assets/e9d8691d-880e-4441-a1cc-55ab765be069" />

Edit:

In a test run, the codex-tui.log file was 983,554 bytes at the time I measured it. In that same window, I saw 49 repeated 403 Forbidden "tool suggestion" errors, and those entries (including the full HTML body being logged) accounted for 545,464 bytes, which is 55.46% of the file.

That comes out to about 1.79 of those events per minute over a 27.37 minute span.

If it helps, I can share another sample with exact timestamps

Couple of issues which may be causing the slowdown @etraut-openai

• Filesystem pressure when log is huge: at 100GB, allocation/journaling/extent management and low-free-space behavior can increase append latency even for small writes.
• System-level contention: backup/indexing/AV tools often inspect large, frequently-changing files; that steals I/O/CPU and hurts interactive responsiveness.
• Async logger queue stress: bursts from many agents can overflow/saturate the non-blocking logging pipeline, increasing contention and event-processing overhead.
• Users will not realize the file size is getting large , logging becomes a sustained disk-I/O tax; if disk is near full and users will have no clue where to check in the first place
• when users run multi-agent runs , generate many more concurrent traces (tool calls, status transitions, span start/end), so log throughput grows superlinearly with agent count and makes the above effects visible faster.

I found that codex-tui.log had grown to about 9 GB under WSL.
After truncating that file, my memory usage dropped from around 90% to 70%.

In a few days, my codex-tui.log has grown to 204GB, and filled my hard disk space, which resulted in "disk full" errors.

Deleting the log or truncating it manually fixes the "disk full" issue. This appears to be a codex CLI issue

my codex-tui.log is 50+ gb this is insane , should not be allowed to grow like this

@sterlingcrispin, it sounds like you're hitting some condition that's generating a lot of log content. Could you tail that file and see if you can figure out what's generating the noise? If we can figure out what's causing this, I can look at suppressing it. Thanks!

@etraut-openai sure, some info from codex

I tailed and sampled /home/sterling/.codex/log/codex-tui.log. It is currently about 63.8 GB decimal / 59.4 GiB, and it was still growing at about 1.6 MB/s during the check. Ubuntu 24.04.4 LTS (Noble Numbat). Kernel: Linux 6.17.0-23-generic Architecture: x86_64 codex-cli version: 0.130.0 npm package: @openai/codex@0.130.0 log path: ~/.codex/log/codex-tui.log size observed: 63,788,716,697 bytes open writers: 22 codex file descriptors via lsof custom verbose env: no RUST_LOG/OTEL/OPENAI env found; only CODEX_MANAGED_BY_NPM=1 Main issue: Each log line is carrying a huge tracing span prefix: session_loop{...}:submission_dispatch{...}:turn{...}:turn{...}:turn{...}:... In recent samples, individual log lines were ~85 KB to ~106 KB, with up to ~150 nested :turn{...} spans. Each nested turn span also repeats token usage fields, often duplicated, so small INFO/WARN messages become very large. Top repeated messages in a recent 100 MB sample: - ~509 lines / 25.0 MB: codex_core_skills::loader: ignoring interface.icon_large: icon path must not contain '..' - ~508 lines / 24.9 MB: codex_core_skills::loader: ignoring interface.icon_small: icon path must not contain '..' - ~507 lines / 24.9 MB: codex_core_plugins::manifest: ignoring interface.defaultPrompt: maximum of 3 prompts is supported - ~168 lines / 8.4 MB: codex_core::client: new - ~164 lines / 8.2 MB: codex_core::client: close - ~84 lines / 4.1 MB: codex_core_plugins::manifest: ignoring interface.defaultPrompt: prompt must be at most 128 characters - ~48 lines / 3.4 MB: codex_core::tasks: new Concrete invalid plugin inputs: - ~/.codex/.tmp/plugins/plugins/build-ios-apps/.codex-plugin/plugin.json has defaultPrompt longer than 128 chars. - ~/.codex/.tmp/plugins/plugins/plugin-eval/.codex-plugin/plugin.json has too many defaultPrompt entries. - ~/.codex/.tmp/plugins/plugins/twilio-developer-kit/.codex-plugin/plugin.json has too many defaultPrompt entries. - ~/.codex/.tmp/plugins/plugins/openai-developers/.codex-plugin/plugin.json has too many defaultPrompt entries. - Twilio plugin skills have 54 agent YAML files with icon_small/icon_large like "../../../assets/logo.svg", which triggers the icon path warnings. The short version: the repeated plugin/skill warnings are the visible noise, but the real blow-up is the tracing span context accumulating many nested turn{...} spans onto every log line. I did not truncate or rotate the file.

seems like I could probably safely delete the whole thing but I might try to prune out these info/warn logs

Hey @etraut-openai, I opened a PR that should address the log growth issue. It fixes the tracing span nesting that was making repeated log events balloon into huge lines.

There’s a separate core skills loader issue too (which was spamming the logs): some plugin skill configs reference shared plugin icons via ../../assets/logo.svg, which the loader currently rejects. I put that in a separate fix since it seems out of scope for the logging PR.

Logging fix: https://github.com/openai/codex/compare/main...b-nnett:fix-root-turn-spans

Core skills fix: https://github.com/openai/codex/compare/main...b-nnett:fix-plugin-shared-skill-icons

Logging issue write-up: https://gist.github.com/b-nnett/be3c669166b320ea70df5cac36ce13dc

Core skills issue write-up: https://gist.github.com/b-nnett/a390c227c22333206caee0061dea8509

@b-nnett thank you this is great, going to write a script that prunes this rather than needing to delete the whole file on my end @etraut-openai if possible it would be great to land a fix to this asap

my codex-tui.log grew another 30gb in the last 5 days

Additional datapoint from codex-cli 0.133.0 on macOS 26.1 / arm64 via Homebrew:

• ~/.codex/log/codex-tui.log had grown to 71,357,455,830 bytes (~66.5 GiB)
• startup / doctor / resume were badly degraded until the file was truncated
• there was also a large active session set (2,937 files / 3.43 GB) and ~/.codex/logs_2.sqlite at 844,046,336 bytes, but the TUI log was by far the single biggest file

So this is not just cosmetic disk growth; once the log gets large enough it appears to contribute materially to CLI slowness.

Having this problem as well. I have mine in a different location due to a custom ~/.ai/ setup I use to have a more homogenous Codex + Claude Code cooperation, but I still suffer from a log that is several tens of gb.