Add an opt-in automatic update setting for Codex CLI

Open 💬 2 comments Opened Jul 22, 2026 by EateralSpirial

What variant of Codex are you using?

Codex CLI on Linux.

What feature would you like to see?

Please add an opt-in setting that lets Codex CLI automatically install available updates, without requiring the user to manually run codex update whenever a new release is published.

Codex already has:

check_for_update_on_startup = true

This checks for updates and surfaces the update UI, but it does not provide a persistent user preference to automatically apply updates.

A possible minimal configuration would be:

auto_update = true

A more extensible design could be:

[updates]
mode = "automatic" # "automatic", "prompt", or "disabled"
channel = "stable"

Expected behavior

When automatic updates are enabled, Codex should:

Check for a stable update at startup, using the existing update-check cache where appropriate.
Detect the active installation method, as codex update already does.
Apply the update automatically when the installation target is writable.
Avoid interrupting or replacing binaries during an active Codex session.
Report update failures clearly and continue launching the current version.
Keep the current prompt-based behavior as the default, so automatic installation remains opt-in.

For standalone installations, an atomic release switch would be ideal. For npm, pnpm, bun, and Homebrew installations, Codex should use the same install-method-aware logic as the existing updater and avoid invoking privileged commands automatically.

Why this is useful

Codex CLI releases are frequent. On Linux machines that use Codex every day, repeatedly launching Codex, seeing an update, exiting or approving the update, and restarting creates avoidable friction. Users can build an external systemd timer, but update policy belongs naturally beside the existing update-check configuration and built-in updater.

Related issues

#9274 requested a built-in manual update command. That command now exists.
This request is specifically for a persistent, opt-in automatic-update policy.

View original on GitHub ↗

2 Comments

saigonbaddielover · 1 month ago

Supporting this request from Codex CLI 0.146.0 on Windows with a global npm installation.

The current update check is already non-blocking and cached, but applying an update still interrupts the launch path: the startup prompt exits the TUI and synchronously runs the package-manager update. With frequent CLI releases, that makes starting a work session pay the update cost.

The important acceptance criterion for me is no update installation on the interactive launch path. A practical opt-in flow could check during a session, apply after a clean TUI exit or during an idle window, and report the installed version on the next launch. On Windows/npm, the implementation should avoid replacing the package while the running binary is locked; #21872 and #23320 show why lifecycle handling matters.

There is useful prior context in #16230 and #12801. The latter auto-selected the existing synchronous startup updater, but explicitly did not implement background updates, so it would not remove this launch-time wait.

I would be happy to test a Windows/npm implementation.

rebroad · 23 days ago

The current standalone daemon updater is a serious security and consent concern, beyond ordinary update UX. app-server daemon bootstrap starts a detached updater; codex-rs/app-server-daemon/src/update_loop.rs fetches https://chatgpt.com/codex/install.sh and executes the response bytes with /bin/sh after an initial delay and then hourly. This is effectively periodic remote-code execution with no user confirmation or artifact signature verification. The installer also writes an export PATH=... block to the selected shell startup file, so the background updater can silently mutate a user's .bashrc (or execute any future changes made to the hosted script). A compromise of the installer endpoint, CDN, or delivery path would therefore execute attacker-controlled shell commands in the user account.

Suggested resolution: remove automatic execution of remote installer scripts; make updates explicit and opt-in; if background updates are retained, download immutable/signed release artifacts, verify signatures before installation, sanitize inherited installer environment, and clearly report/ask consent before enabling the updater. The updater should never pipe network response bytes directly to a shell. This also relates to #32785 and #24035.