Codex CLI should announce when an updated version is available

I actually noticed this for the first time when I started codex today and was happy to get the notification!
<img width="453" height="268" alt="Image" src="https://github.com/user-attachments/assets/5fe192c7-e78c-48b3-947e-4f05103698b7" />

Not sure if that works the same on all platforms - I'm on macOS. I really like the idea of a single-command update, but this new feature is definitely a step in the right direction.

I actually noticed this for the first time when I started codex today and was happy to get the notification!

@someone-in-texas Interesting.. I thought I saw some commits recently alluding to a feature like that, but when I opened it this morning (knowing there was an update available) I didn't see it; maybe I was too quick to manually update.

Seems the update check was added in:

• https://github.com/openai/codex/pull/1764
• > 1. Ping https://api.github.com/repos/openai/codex/releases/latest (at most once every 20 hrs)
• > 2. Store the result in ~/.codex/version.jsonl
• > 3. If CARGO_PKG_VERSION \< latest_version, print a message at boot.

And then more recently the banner was tweaked to be more visible in:

• https://github.com/openai/codex/pull/2537
• > previously the upgrade banner was disappearing into scrollback when we cleared the screen to start the tui

Looking at the relevant code for it, it seems it does already detect whether installed by brew or npm and changes the command shown based on that as well:

https://github.com/openai/codex/blob/4e9ad238649c71690cbb0402e110943223c16fcd/codex-rs/tui/src/lib.rs#L256-L301

Looking in my ~/.codex I don't see a version.jsonl, but I do see a version.json, and looking at the code, that seems to actually be the correct file:

https://github.com/openai/codex/blob/4e9ad238649c71690cbb0402e110943223c16fcd/codex-rs/tui/src/updates.rs#L54-L59

It currently has the following:

{"latest_version":"0.24.0","last_checked_at":"2025-08-27T07:27:24.800101Z"}

The date is currently '2025-08-28T02:07:56.052Z', so doing some quick maths:

const d1 = new Date("2025-08-27T07:27:24.800101Z");
const d2 = new Date("2025-08-28T02:07:56.052Z");

const diffMs = d2 - d1; // difference in milliseconds
const diffHours = diffMs / (1000 * 60 * 60); // convert to hours

console.log(diffHours); // ~18.67 hours

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:

 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

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.

Really appreciate the detailed breakdown you shared!

@someone-in-texas Happy to :) I figured I was looking for my own understanding, so may as well share what I found as context on the issue for everyone else's benefit too.

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.

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.

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.

As noted in the thread above, codex CLI now announces when a new version is available. Thanks again for the suggestion!

@etraut-openai Has the 20 hour window discussed above also been fixed to
Something more reasonable like 1 day?

If not; this probably shouldn't be closed?

Has the 20 hour window discussed above also been fixed

@etraut-openai According to GitHub Codex (GPT-5), it's still an issue, so this shouldn't have been closed based on your reasoning in https://github.com/openai/codex/issues/2806#issuecomment-3458892095:

Short answer: it’s still 20 hours. Evidence: in codex-rs/tui/src/updates.rs the check is: ``rust Some(info) => info.last_checked_at < Utc::now() - Duration::hours(20), `` Permalink to the relevant code: codex-rs/tui/src/updates.rs (line shown in context): https://github.com/openai/codex/blob/ab63a47173e57c8bdf9ec442964dd0d47007f2dc/codex-rs/tui/src/updates.rs#L14-L21 Based on that, it has not been changed to 24 hours.

---

Edit: I just created a new issue for it specifically:

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