TUI rate-limit items can appear in concurrent tabs even when rollout events keep rate_limits=null

Resolved 💬 2 comments Opened Mar 18, 2026 by Astro-Han Closed Mar 18, 2026

What version of Codex is running?

codex-cli 0.115.0

What subscription do you have?

No response

Which model were you using?

gpt-5.4

What platform is your computer?

macOS 26.3.1

What issue are you seeing?

With five-hour-limit and weekly-limit enabled in the TUI status line, concurrent Codex tabs can behave inconsistently.

In my repro, both tabs started without the rate-limit items. Later, one tab began showing 5h 94% and weekly 16%, but the corresponding rollout events still had rate_limits: null for every token_count event.

This seems like a TUI/runtime inconsistency rather than a config inheritance issue.

What steps can reproduce the bug?

  1. Add five-hour-limit and weekly-limit to [tui].status_line in ~/.codex/config.toml.
  2. Open two Codex TUI tabs at the same time.
  3. Start them in different project directories.
  4. Watch the status line during startup and after a short delay.
  5. Compare the visible status-line values with the session rollout-*.jsonl events.

What is the expected behavior?

The rate-limit items should be consistent across tabs, and if the TUI shows 5h / weekly, that state should also appear in the rollout event stream.

Additional information

Other status-line items stayed consistent, so this does not look like a general config inheritance problem.

I am omitting local paths and raw session files because they contain machine-specific information, but I can provide sanitized event excerpts if needed.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗