Limit reset time format not consistent

Open 💬 2 comments Opened Jun 16, 2026 by Richienb

What version of Codex CLI is running?

0.140.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

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

_No response_

Codex doctor report

What issue are you seeing?

When I run /status, for the 5-hour and weekly limits, the time they will reset is displayed as 24-hour time:

│  5h limit:             [░░░░░░░░░░░░░░░░░░░░] 0% left (resets 16:10)                                     │
│  Weekly limit:         [████░░░░░░░░░░░░░░░░] 20% left (resets 02:12 on 22 Jun)                          │

But, when I hit my usage limit, I get an error that uses 12-hour time:

■ You've hit your usage limit. Upgrade to Pro (https://chatgpt.com/explore/pro), visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at 4:10 PM.

What steps can reproduce the bug?

See above

What is the expected behavior?

Both messages should use the same error format.

It seems that the usage limit error is obtained from an API, which might be difficult to change, so that means the /status output should be changed to use 12-hour time.

Additional information

_No response_

View original on GitHub ↗

2 Comments

MakenRosa · 2 months ago

I took a look at this and the mismatch appears to be local to the status rendering path.

Findings:

/status rate-limit reset labels are formatted through codex-rs/tui/src/status/helpers.rs::format_reset_timestamp.
That helper currently uses dt.format("%H:%M"), which explains the 24-hour output such as 16:10 and 02:12 on 22 Jun.
The rate-limit display code calls this helper from codex-rs/tui/src/status/rate_limits.rs for both normal rate-limit windows and spend-control/monthly limit reset labels.
The usage-limit error path already formats retry timestamps with %-I:%M %p in codex-rs/protocol/src/error.rs::format_retry_timestamp, which explains the 4:10 PM style in the error message.

A minimal fix seems to be:

-    let time = dt.format("%H:%M").to_string();
+    let time = dt.format("%-I:%M %p").to_string();

I also checked the expected behavior locally with focused tests around the examples from this issue:

same-day reset: 2026-06-16 16:10 -> 4:10 PM
later reset: 2026-06-22 02:12 -> 2:12 AM on 22 Jun

The relevant snapshots under codex-rs/tui/src/status/snapshots/ need to be updated as part of the final change, since several expected /status rows currently contain 24-hour reset labels. I verified that the affected status snapshots update to the 12-hour format, including narrow/wrapped rows.

Local validation in WSL/Ubuntu:

cargo fmt --check --package codex-tui passed
cargo test -p codex-tui format_reset_timestamp --lib passed: 2 tests passed
cargo test -p codex-tui status_snapshot --lib passed after refreshing the affected status snapshots: 24 tests passed
git diff --check passed

If this direction matches the intended UI behavior, this should be a very small change: update the helper, add the two focused unit tests above, and refresh the status snapshots.

nm-z · 17 days ago

Additional current reproduction with Codex CLI 0.147.0:

│ Weekly limit: [███████████████░░░░░] 75% left (resets 13:31 on 15 Aug) │

My terminal locale explicitly uses 12-hour time:

LANG=en_US.UTF-8
LC_TIME="en_US.UTF-8"
LC_ALL=
t_fmt=%r
date +%X: 01:48:48 PM

Despite that, /status formats the reset time as 13:31. The formatter should respect LC_TIME rather than hard-coding either 12-hour or 24-hour output.