Opt-in reconciliation of self-updated Cask installation records without reinstalling

[joseph1020]

Problem

Homebrew can inspect the actual application bundle version for certain self-updating Casks, but its recorded installation version may remain outdated after an in-app update.

As a result, brew outdated --greedy can report an application as outdated even when the installed application already matches the latest Cask version. Currently, reconciling Homebrew's installation record through supported commands may require reinstalling an already up-to-date application.

Verified examples

1. iTerm2

iTerm2 updated itself from 3.7.4 to 3.7.6, while Homebrew still recorded 3.7.4.

Consequently, brew outdated --greedy reported an outdated Cask.

Running brew upgrade --cask --greedy iterm2 reconciled the installation record, but required replacing an already up-to-date application.

2. Zoom (pkg-based Cask)

Zoom provides a second verified example involving a self-updating Cask installed through a .pkg artifact.

The observed state was:

Property	Value
Homebrew recorded installed version	7.2.2.88465
Current Cask version	7.2.5.90525
Actual installed app (CFBundleVersion)	7.2.5.90525
Actual installed app (CFBundleShortVersionString)	7.2.5 (90525)
auto_updates	true
JSON outdated	false
JSON bundle_version	null
JSON bundle_short_version	null

However, brew outdated --greedy zoom reported:

zoom (7.2.2.88465) != 7.2.5.90525

The installed application's bundle version exactly matches the current Cask version, yet Homebrew's recorded installation version remains outdated.

Unlike iTerm2, Zoom uses a .pkg installer. This illustrates why any proposed reconciliation mechanism should account for different installation methods and avoid assumptions about how application versions are identified.

Proposal

I recognise that similar requests were previously declined in issues #15932 and #16200.

Rather than automatically synchronising installation records during brew update, would maintainers consider an explicit, opt-in reconciliation operation that updates the recorded installed version when the local application can be reliably verified?

Ideally, such an operation would:

• Require explicit user invocation, with a dry-run option.
• Verify the actual installed application and its version against the current Cask definition.
• Avoid downloading, reinstalling, or replacing an already up-to-date application.
• Refuse reconciliation when the application's identity or version cannot be established reliably.
• Preserve Homebrew's installation metadata consistency and existing safety guarantees.

Support for .pkg-based Casks could be considered separately if their installation metadata introduces additional constraints.

Question for maintainers

Is updating a Cask's recorded installed version independently of an actual Homebrew installation compatible with Homebrew's installation-state invariants?

If not, is there an alternative supported mechanism for reconciling installation records after an application updates itself?

The intention is not to change the meaning of --greedy, but to provide a safe way to reconcile stale installation records without unnecessary reinstalls.

---

This proposal was researched and drafted with assistance from OpenAI ChatGPT (GPT-6), and reviewed by the submitter.