High invisible output churn when idle (request for regression test or to fix the suppressed bug)

What version of Codex CLI is running?

v0.101.0, bug found on v0.98.0

What subscription do you have?

pro

Which model were you using?

gpt-5.3-codex (high)

What platform is your computer?

Linux 6.18.8-arch2-1 x86_64 unknown

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

Suckless terminal with tmux 3.6a used as an output probe (bug happens without tmux)

What issue are you seeing?

Note: In v0.99.0+, this bug is suppressed, but indirectly, allowing it to come back.

On v0.98.0, I found tmux itself was taking 32GB of memory, 20GB from a single pane running a Codex session that had been sitting at a yes/no permission prompt for 2-3 days. I've had a few system crashes lately in the past few weeks that I think were caused by memory exhaustion that I'm hoping are caused by this, but I haven't gone back to see how long this bug was happening in Codex.

Codex found until v0.98.0, that the blinking dot for the Running... line before the yes/no prompt was causing 78 KB/sec of terminal output. If I understand right, it was redrawing the entire terminal every 32ms to handle the blinking dot.

Knowing I wasn't on the most recent version, I asked Codex to look at the problematic code and see if it had been fixed between v0.98.0 and main, and it said no changes hade been made. I wanted to reproduce this on v0.101.0 to be sure, and couldn't. So, I had Codex bisect itself to find the commit that fixed the bug. I was just curious on digging into why it had missed it. It found your #11217 fixing a separate issue somehow suppresses the crazy amount of terminal output that I experienced.

I was leaning toward moving on, thinking this report would just be saying "there was a bug a week ago that got suppressed so it's not currently a problem", but I asked Codex if this should be reported, and to analyze if it was reported if it should just be closed as won't fix / not a bug. It said to report it, because a regression test should be added to ensure that a Codex session while idle (or idle other than a blinking dot) isn't going crazy on unnecessary screen redraws. So, here's the report and I'll understand if it's not a high priority.

Because your commit fixes a different bug which somehow suppresses this one rather than fixes it, I think it makes sense to either implement a fix to the (currently not problematic) bug here or to create a regression test to make sure it or something else doesn't cause crazy amounts of unnecessary terminal redraws.

Leaving the underlying behavior risks letting Codex go back to crashing some systems in rare cases where all output is being logged, like tmux's scrollback.

From Codex's analysis, it's my understanding that while a dot is blinking, that Codex is redrawing the entire screen every 32ms. That could be enough of a bug to fix itself, but it's not that huge of an issue since it won't last very long. I guess if a command took a really long time to run and wasn't timed out that this could still be an issue.

Possible root cause fixes could be: Using an ANSI blink attribute on the dot if the terminal supports it; adding a config option to prevent animations; only redrawing the terminal at the 32ms cycle if the dot needs to change being on or off (there's some code which does this in some scenarios, but Codex says this particular code path doesn't use it);

What steps can reproduce the bug?

Historical repro on bug-present commit (b2d3843109) (last on v0.98.0):
Step 1: Build and run target/debug/codex.
Step 2: Get Codex to show a blinking dot that stays on the screen. (i.e. Ask Codex to touch ~/<random>, causing a permission prompt.)
Step 3: At Would you like to run the following command?, observe how much terminal output Codex is making.

• I'm sure there's other ways to check this (maybe just a stdout redirect), but with tmux you can sample once per second over time with `tmux list-panes -t <pane> -F 'hist_bytes=#{history_bytes} hist_lines=#{history_size}' and see Codex is making a ton of invisible terminal output when it's idle other than the blinking dot.

What is the expected behavior?

In an idle approval/wait state, terminal output should be none, or minimal. Certainly not 20GB of terminal output over 2-3 days while sitting at the yes/no prompt.

Additional information

I'm attaching a document Codex wrote when I asked it what it would need to know to reproduce this and fix it in a different context window (running on OpenAI's accounts rather than mine.) In short, it summarizes:

• Likely pre-fix mechanism:
• noisy file watcher events -> SkillsChanged -> SkillsUpdateAvailable -> forced skill reload path -> recurring output activity in idle prompt state.
• #11217 mitigated this by:
• filtering watcher events to mutating kinds (Create/Modify/Remove), and
• removing per-event info logging in watcher loop.
• Suggested action (tmux-independent):
• add a PTY-based regression test for idle approval output budget (bytes over N seconds under stable semantic state).

tmux-codex-history-bytes-investigation-2026-02-15-v2.md