fix(server): only run provider updates through the installer that owns the binary

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.

[juliusmarminge]

Problem

T3 Code could pick an update command from one installation while the active executable belonged to another:

• a standalone Codex install (~/.codex/packages/standalone/) got npm install -g @openai/codex@latest, which never touches it, so the advisory looped forever ([Bug]: Codex "Update now" runs npm install -g against installs it never verified are npm-managed, causing a permanent "still needs an update" loop #5629)
• a brew install claude-code@latest keg got brew upgrade claude-code, which fails ([Bug]: Provider auto-update ignores which Homebrew formula is actually installed for claude-code #6245)
• Homebrew casks were compared against npm's latest, which lands hours before the cask bump, so brew upgrade could never clear the advisory ([Bug]: Homebrew-installed Codex/Claude flagged outdated against npm latest, brew upgrade cannot clear it #7730)

Fix

Ownership is derived from the resolved executable's real path, and a package manager is only invoked against an install it has evidence of owning:

Evidence	Command	Latest
Native installer path	<resolved binary> update	npm registry
…/Cellar/<name>/ or …/Caskroom/<name>/	brew upgrade [--cask] <name>	brew info --json=v2
<prefix>/lib/node_modules/<pkg>/	npm install -g --prefix <prefix> <pkg>@latest	npm registry
pnpm / bun / vp global paths	as before	npm registry
anything else	manual-only, version gap still shown	npm registry

The npm prefix is pinned because the npm on PATH can belong to a different Node than the one that owns the provider. Native installs share npm's version train, so the registry stays authoritative for them and native users keep their launch toast.

Resolution is cached per instance for an hour. The maintenance runner re-reads it fresh immediately before executing, refuses with "Provider installation changed" if the lock key moved since the advisory, and reads fresh again afterwards so a Homebrew upgrade's new latest is reflected. Settings tracks in-flight updates per instance instead of per driver.

Docs: docs/internals/providers.md gains a "Provider updates" section; docs/user/install.md gains "Keeping Provider CLIs Current".

Relationship to #6436

Supersedes #6436 by @ettoc00, which identified the same root cause and whose npm --prefix pinning, Homebrew formula/cask detection, and per-instance settings state are carried over here. The rest of that PR (Scoop, WinGet, Grok native, identity hashing, wrapper-script parsing, the "Check for updates" affordance) is left out: the native-install branch there dropped latestVersion to null, which removed update notifications for the default Claude/Codex/OpenCode install paths, and the Vite+ detector shelled out to vp root -g, which does not exist. Scoop/WinGet support is worth its own issue with a Windows validator.

Closes#5629
Closes#6245
Closes#7730

Verification

• apps/server, apps/web typecheck; vp lint on touched files
• 224 server tests across the touched files, 53 web tests in the touched files
• New coverage: npm prefix pinning via real symlinks in a temp dir, POSIX/Windows/nested prefix parsing, Homebrew cask through a fake spawner asserting exactly one brew info call, keg/cask/plain-/usr/local/bin ownership (fix(server): avoid treating Ubuntu binaries as Homebrew-managed #8832 case), cache-until-fresh, runner re-resolve ordering, lock-key-changed abort with no spawn
• Not exercised against a real Homebrew keg on macOS; parsing and command shape are unit-tested

Written by Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how update commands are chosen and executed (including spawning brew during resolution); wrong ownership logic could block valid updates or run the wrong installer, but unproven paths fail closed to manual-only.

Overview
Provider one-click updates now infer who installed the CLI from the resolved executable and its real path, instead of assuming npm/Homebrew defaults. Unproven installs stay manual-only (canUpdate: false) while still showing version gaps; proven paths get the matching command (native update, brew upgrade [--cask] <name> with brew info for “latest”, npm with pinned --prefix, pnpm/bun/vp globals). Codex gains standalone-installer updates; Cursor binds updates to the resolved cursor-agent path.

API shape: snapshots expose resolveMaintenance() (hourly cache, { fresh: true } to re-derive) instead of a static maintenanceCapabilities. The registry resolves maintenance from the instance registry (not stale reconciliation state) and supports optional fresh. The update runner re-resolves before spawn and aborts if the lock key changed (“Provider installation changed”), then re-resolves after success for post-upgrade advisories.

UI: provider settings track in-flight updates per instance and show inline “Update now” when canUpdate is true for that instance.

Docs add provider-update internals and user-facing “Keeping Provider CLIs Current.”

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

Note

Run provider updates only through the installer that owns the binary path

• Replaces the static maintenanceCapabilities value on ServerProviderShape with a cached resolveMaintenance effect that performs path-based resolution.
• Adds filesystem and child-process probes in providerMaintenance.ts to verify the real executable path belongs to a supported installer (npm, Homebrew, pnpm, Bun, or native).
• providerMaintenanceRunner.updateProvider now performs a fresh capability resolution before command execution and aborts the update if the lock key differs from the cached capability.
• Risk: Missing, unresolved, or mismatched installations now return manual-only capabilities, disabling one-click updates for paths that cannot be mapped to a supported installer.

^{Macroscope summarized 98c0e32.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+2 B (+0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+3 B (+0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.3 KiB	−176 B (−1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−173 B (−2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	56.4 KiB	−1.4 KiB (−2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 66419a1 · PR result: 98c0e32 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This XL PR substantially rewires provider update ownership detection, advisory resolution, command execution, post-update verification, and per-instance settings behavior across server and web code. The changes affect which installers can run on a customer machine and add cross-platform filesystem and Homebrew process probing, creating a runtime scope that requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

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

[ettoc00]

Quick Windows validation update: Scoop and WinGet both completed real provider updates successfully across Claude and OpenCode through the actual resolver + maintenance runner, including a same-provider Scoop/WinGet coexistence case where only the explicitly selected installation was updated.

I also found one generic post-update edge case on Windows: if the updater exits successfully but the provider disappears or its installation can no longer be ownership-verified afterward, the runner can still report succeeded simply because it is no longer behind_latest.

Separately, I found a few test-only Windows portability issues in the existing fixtures, e.g. POSIX/macOS symlink fixtures hitting EPERM, a Darwin fixture being evaluated with Windows path semantics, and a /tmp expectation that isn’t host-normalized.