fix(server): upgrade the actually-installed Homebrew formula

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.

[rohitashwin]

Problem

Auto updating provider in T3 Code Desktop for macOS (e.g., claude-code) would fail because claude-code was installed using homebrew using the command brew install claude-code@latest rather than brew install claude-code. T3 Code would try to run brew upgrade claude-code which fails. The correct approach is to find the right install variant of claude-code actually installed on the machine. This PR does that and automatically calls brew install claude-code@latest.

What Changed

Provider auto-update no longer relies solely on each driver's hardcoded default Homebrew formula name. resolvePackageManagedProviderMaintenance now extracts the actual installed formula name from the resolved Homebrew Cellar/Caskroom path (e.g. .../Caskroom/claude-code@latest/2.1.228/claude) and runs brew upgrade against that formula, falling back to the driver's default when the path can't be parsed.

Why

ClaudeDriver.ts hardcodes homebrewFormula: "claude-code". Anyone who installed via brew install claude-code@latest (a different formula from plain claude-code) gets brew upgrade claude-code from the in-app update control, which fails loudly:

$ brew upgrade claude-code
==> Downloading Homebrew API data
Error: Cask 'claude-code' is not installed.
$ echo $?
1

Fixes#6245

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Test plan

• pnpm exec vitest run src/provider/providerMaintenance.test.ts — 18/18 pass, including a new case covering a Homebrew install under a different formula name than the driver's default
• Verified against this machine's actual claude install (/opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code@latest/2.1.228/claude): resolver now produces brew upgrade claude-code@latest instead of the failing brew upgrade claude-code

---

Note

Low Risk
Localized change to provider maintenance command resolution with new unit tests; no auth or data-path impact.

Overview
Provider auto-update now builds brew upgrade from the formula name on disk, not only each driver’s default homebrewFormula.

When a binary resolves through Homebrew, the resolver parses the installed formula from Cellar/Caskroom paths (e.g. package-tool@latest or claude-code@latest) and passes it into Homebrew maintenance capabilities. resolveHomebrewFormula keeps tap-qualified names like example/tap/scoped-package-tool when the path basename matches the definition; otherwise it uses the detected installed name. If nothing can be resolved, behavior still falls back to the definition default or manual-only updates.

Tests cover tap-qualified formulas and variant formula names that differ from the driver default.

^{Reviewed by Cursor Bugbot for commit d71fabd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix Homebrew upgrade to target the actually-installed formula instead of the definition default

• Adds extractHomebrewFormulaFromPath to detect the installed Homebrew formula from a binary's Cellar/Caskroom path, and resolveHomebrewFormula to pick between the installed and definition formulas, preferring the tap-qualified definition name when basenames match.
• Updates makeHomebrewProviderMaintenanceCapabilities to accept an optional installed formula and use the resolved formula in the brew upgrade command, falling back to manual-only capabilities when no formula is available.
• Updates resolvePackageManagedProviderMaintenance to extract the installed formula from command paths and pass it into the capabilities factory.
• Behavioral Change: brew upgrade commands now target the detected installed formula (e.g. package-tool@latest) rather than the static definition formula when they differ.

^{Macroscope summarized d71fabd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 855008a1-8a81-4736-a99c-51ad50c39789

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 805e2f1a99130dbb2f22adbd7117e6ce7fe3b3bb. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix modifies which formula name is passed to brew upgrade commands at runtime. While the logic is straightforward with good test coverage, the change affects actual system behavior during package upgrades, warranting human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[rohitashwin]

Good catch — that was a real regression, not a hypothetical. Homebrew's Cellar path is keyed by the formula's bare name only (rack = HOMEBREW_CELLAR/name in formulary.rb), so a tap-qualified formula like anomalyco/tap/opencode (OpenCode's driver) could never be recovered from the path, and my extraction would have silently swapped it for the bare opencode, which Homebrew's FromNameLoader can resolve to a different tap's formula or raise TapFormulaAmbiguityError.

Pushed a fix: the extracted formula only overrides the configured homebrewFormula when it actually diverges from that formula's basename (e.g. claude-code vs. the installed claude-code@latest). When they match, the configured tap-qualified name is kept as-is. Added a regression test (keeps the tap-qualified Homebrew formula when the Cellar path only has the bare name) using the existing scoped-package-tool fixture, which mirrors OpenCode's example/tap/scoped-package-tool shape. Full suite (19 tests) passes.

[juliusmarminge]

Closing in favor of #6436, which includes the installed Homebrew formula fix, preserves tap-qualified names, and handles cask upgrades. Keeping provider-update review there. Thanks for the fix and follow-up regression coverage.