rate_limits is always null in rollout session files

[Loongphy]

What version of Codex CLI is running?

0.114.0

What subscription do you have?

Team

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 unknown

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

Windows Terminal

What issue are you seeing?

In local Codex session rollout files, token_count events are present, but the rate_limits field is always null.

Because of this, tools like https://github.com/Loongphy/codex-auth that inspect ~/.codex/sessions/**/ rollout-*.jsonl cannot determine the actual rate limit state from the latest rollout file.

What I observed

The latest rollout file contains token_count events, but rate_limits is null
in those entries.

Example pattern:

{
  "type": "event_msg",
  "payload": {
    "type": "token_count",
    "info": {
      "total_token_usage": {
        "input_tokens": 14676,
        "output_tokens": 412,
        "total_tokens": 15088
      },
      "model_context_window": 258400
    },
    "rate_limits": null
  }
}

What steps can reproduce the bug?

1. Run Codex CLI normally in a workspace.
2. Locate the newest file under ~/.codex/sessions/**/rollout-*.jsonl.
3. Search for token_count or rate_limits.
4. Observe that rate_limits is recorded as null.

What is the expected behavior?

• rate_limits should contain the actual rate limit metadata when available
• It happens after gpt-5.4 model released.

Additional information

No response

[Astro-Han]

Additional data point from normal TUI usage (not codex exec): I can reproduce the same rate_limits: null behavior on codex-cli 0.115.0 with gpt-5.4 on macOS.

In two concurrent TUI tabs, both sessions initially started without five-hour-limit / weekly-limit in the status line. Later, one tab began showing 5h 94% and weekly 16%, but the corresponding rollout-*.jsonl files for both sessions still had rate_limits: null for every token_count event.

So this seems broader than exec-mode JSONL output alone. At least in TUI, there appears to be a divergence between:

• the rate-limit state rendered in the UI
• the rate-limit state persisted into rollout events

I opened #15054 for the TUI symptom, but it looks like the same underlying issue from a different angle.

[Loongphy]

the rate-limit state rendered in the UI

/status fetch the usage api so that you can see accurate usage limit info in TUI

[jazzyalex]

This bug (or it was done intentionally?) break all limit trackers who were using json parser to get it.

Like my jazzyalex.github.io/agent-sessions
macOS • open source • ⭐️ 385

Would be great to hear form oAI whether it will be fixed or not.