Switch CLI update check to “once per calendar day” based on local timezone (have-we-checked-today) instead of 20h

What feature would you like to see?

• Change the CLI update check interval to "at most once per calendar day" rather than a strict hour-based interval. The logic should check if an update has been performed during the current local calendar day and skip redundant checks until the next day.

Why?

• This prevents notification drift and is more predictable for daily CLI users.
• Strict hour-based intervals (like 20h or 24h) can confuse users who expect a daily cadence.
• Local timezone aligns with daylight hours and user expectations, especially for distributed teams.

Implementation notes:

• Store the last check date (potentially still as a UTC timestamp to align with existing implementations) and compare to the current local calendar day.
• Consider adding a "force update check" flag/env for manual triggers.

Additional information

See the full discussion, references, and suggested solutions where it was originally raised in the comments of:

• https://github.com/openai/codex/issues/2806

---

So I guess I just didn't see it this morning because it was within the 20hr window: https://github.com/openai/codex/blob/4e9ad238649c71690cbb0402e110943223c16fcd/codex-rs/tui/src/updates.rs#L14-L30 While I understand the 20-hour window, I’d prefer to see an update straight away when I open the tool, or at least the first time each day in my timezone. The current approach isn’t far off a daily check anyway, it just drifts depending on when I last opened it. Switching to a 'once per local day' rule would make the behavior more predictable, and in practice wouldn’t increase load on the API: it still averages one request per day, with at most two in any 20-hour span. So we could change the check to something like this: ``diff use chrono::{Duration, Utc}; +use chrono::Local; pub fn get_upgrade_version(config: &Config) -> Option<String> { let version_file = version_filepath(config); let info = read_version_info(&version_file).ok(); if match &info { None => true, - Some(info) => info.last_checked_at < Utc::now() - Duration::hours(20), + Some(info) => { + let now_local = Local::now(); + let last_local = info.last_checked_at.with_timezone(&Local); + last_local.date_naive() < now_local.date_naive() + } } { `` Since the conversion from UTC to local time is handled in that check, we can continue storing the update check time in UTC, so wouldn't need to change this part: https://github.com/openai/codex/blob/4e9ad238649c71690cbb0402e110943223c16fcd/codex-rs/tui/src/updates.rs#L66-L92 _Originally posted by @0xdevalias in https://github.com/openai/codex/issues/2806#issuecomment-3231359967_

---

I agree - the "once per local day" idea makes a lot of sense. With the 20-hour window, there's always the chance it drifts and I end up missing a full workday's check, or getting a notification at an odd time. From a developer's perspective, having it tied to the start of each local day seems like it would make the behavior much more predictable and align better with a daily workflow. Really appreciate the detailed breakdown you shared! It might be a bit more than most folks need, but it could be cool if the check frequency was configurable (within reason) in config.toml. That way individual developers could tune it to their workflow, and organizations running Codex in a standardized environment would have the option to disable update notifications entirely and manage updates centrally instead. _Originally posted by @someone-in-texas in https://github.com/openai/codex/issues/2806#issuecomment-3231666210_

---

> it could be cool if the check frequency was configurable (within reason) in config.toml @someone-in-texas Yeah, that was my original thought as well, but then I started thinking that it might end up being too 'nit picky' of a configurable item and end up being more effort / complicate the code more than it's worth. That said, if the implementers were open to it, I wouldn't say no. _Originally posted by @0xdevalias in https://github.com/openai/codex/issues/2806#issuecomment-3232189614_

---

There should absolutely be a flag to enable/disable this. I'm running Codex off of a local git checkout, which makes the banner pointless, annoying, and intrusive: ✨⬆️ Update available! 0.0.0 -> 0.36.0. Gee... thanks for letting me know. Look at me back here on 0.0.0. People wanting to run a fixed version for whatever reason (who knows) may also appreciate a flag. _Originally posted by @fieldtensor in https://github.com/openai/codex/issues/2806#issuecomment-3299795211_

---

> There should absolutely be a flag to enable/disable this. @fieldtensor Haven't personally tested this, but you could probably hack around that in the meantime by setting last_checked_at in ~/.codex/version.json to some date far in the future. _Originally posted by @0xdevalias in https://github.com/openai/codex/issues/2806#issuecomment-3364625934_