›_ Codex Issues
Codex Issues / #6253

Codex CLI should run brew update before brew upgrade (Brew cask update fails without sync)

Resolved 💬 4 comments Opened Nov 5, 2025 by fodor99 Closed Nov 16, 2025
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.53

What subscription do you have?

plus

Which model were you using?

i dont know

What platform is your computer?

apple silicon

What issue are you seeing?

✅ Issue Title

Codex CLI should run brew update before brew upgrade (Brew cask update fails without sync)

⸻

✅ Issue Body

Summary
When Codex is installed via Homebrew (brew install --cask codex), the built-in update flow can fail to detect available updates because it does not run brew update before attempting the upgrade. This results in a stale cask index and a misleading “latest version installed” message, even when a newer version exists.

This creates a user-experience and automation gap between Codex’s internal updater and Homebrew’s package state.

⸻

⸻

Actual Behavior
• Codex reports a new version available (e.g., 0.55)
• Internal updater runs
• Brew reports “already latest”
• After manually running brew update, the upgrade succeeds

This leads to confusion, redundant retries, and friction in managed macOS environments.

⸻

Proposed Solution

  1. Detect Homebrew-installed Codex
  2. Pre-execute:

brew update

  1. Then run:

brew upgrade --cask codex

  1. If Homebrew install detected, disable internal updater and display:

“You installed Codex via Homebrew — updating via Homebrew…
(tip: our updater doesn’t run brew update, so we’re doing that now)”

⸻

Acceptance Criteria
• Brew-installed Codex always updates correctly
• No contradictory “latest version already installed” messages
• Robust behavior in corporate environments (MDM, read-only dirs, proxies)
• Idempotent, scripting-safe behavior

⸻

Nice-to-Have
• codex doctor or --diagnostics mode
• --no-update flag for CI
• Proxy / offline fallback messaging

⸻

Why it Matters
Reduces friction, improves trust in update UX, prevents user confusion, and aligns Codex with macOS package management best practices.

⸻

✅ End of Issue

What steps can reproduce the bug?

Steps to Reproduce

  1. Install Codex via Homebrew:

brew install --cask codex

  1. A new Codex version is released
  2. Launch Codex → update prompt appears
  3. Choose in-app update or run:

brew upgrade --cask codex

  1. Output incorrectly claims the newest version is already installed
  2. Run:

brew update && brew upgrade --cask codex

  1. Upgrade succeeds

⸻

Environment
• macOS (Apple Silicon)
• Codex installed via Homebrew Cask
• Observed with v0.53 → v0.55 transition
• Brew version and taps up to date only after manual sync

⸻

What is the expected behavior?

_No response_

Additional information

Expected Behavior
• When Codex detects a Homebrew cask installation, the CLI should either:
✅ automatically run brew update && brew upgrade --cask codex
or
✅ delegate update operations entirely to Homebrew with clear instructions
• Output should be deterministic and aligned with Brew’s actual package registry state

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 9 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #5971
  • #5681
  • #5607
  • #5515

Powered by Codex Action

gabrielekarra · 9 months ago

Hi @fodor99 !

I found the code that needs to be fixed. In codex-rs/tui/src/updates.rs, line 178:

rust path=/codex/codex-rs/tui/src/updates.rs start=178
UpdateAction::BrewUpgrade => ("brew", &["upgrade", "--cask", "codex"]),

The problem: This only runs brew upgrade --cask codex without syncing the cask index first.

Proposed fix:

We need to modify the command_args() method to support multiple commands or change the approach. A few options:

  1. Run two separate commands - Modify the update execution logic to run brew update first when BrewUpgrade is detected
  2. Use shell with chained commands - Change to ("sh", &["-c", "brew update && brew upgrade --cask codex"])
  3. Add a pre-command field to UpdateAction enum

The cleanest approach would be option 1 - adding logic in the update execution code to run brew update before the main upgrade command when the action is BrewUpgrade.

I can submit a PR with this fix if the approach looks good.

fodor99 · 9 months ago
Hi @fodor99 ! I found the code that needs to be fixed. In codex-rs/tui/src/updates.rs, line 178: `` rust path=/codex/codex-rs/tui/src/updates.rs start=178 UpdateAction::BrewUpgrade => ("brew", &["upgrade", "--cask", "codex"]), `` The problem: This only runs brew upgrade --cask codex without syncing the cask index first. Proposed fix: We need to modify the command_args() method to support multiple commands or change the approach. A few options: 1. Run two separate commands - Modify the update execution logic to run brew update first when BrewUpgrade is detected 2. Use shell with chained commands - Change to ("sh", &["-c", "brew update && brew upgrade --cask codex"]) 3. Add a pre-command field to UpdateAction enum The cleanest approach would be option 1 - adding logic in the update execution code to run brew update before the main upgrade command when the action is BrewUpgrade. I can submit a PR with this fix if the approach looks good.

Yes, it looks good for me. Could you please submit a PR. Thank You!

etraut-openai contributor · 9 months ago

This has been fixed. See this thread for details.