[Baker-Harrison]

What Changed

• Detect Windows provider executables resolved through Chocolatey shims.
• Update Chocolatey-managed OpenCode installations with choco upgrade opencode --yes instead of updating an unrelated npm installation.
• Add regression coverage for Windows Chocolatey command resolution.

Why

On Windows, a Chocolatey OpenCode shim can appear before a newer npm installation on PATH. T3 Code previously probed the older Chocolatey binary but ran the npm updater, reported success, and continued showing OpenCode as too old after restart. The update action now targets the package manager that owns the executable T3 Code actually resolved.

Checklist

• This PR is small and focused
• I explained what changed and why
• No UI changes
• No animation or interaction changes

Verification

• vp test run apps/server/src/provider/providerMaintenance.test.ts
• vp fmt --check on the three changed files
• Targeted vp lint on the three changed files
• vp run --filter t3 typecheck
• Manual Windows verification with a Chocolatey OpenCode shim shadowing a current npm installation

Generated with gpt-5.6-sol via the T3 Code Codex harness.

---

Note

Medium Risk
Changes which external command runs for in-app provider updates on Windows; wrong detection could block updates or target the wrong package manager, though precedence after npm/pnpm/Homebrew is unchanged.

Overview
Fixes Windows provider self-updates when the resolved binary comes from a Chocolatey shim (e.g. OpenCode ahead of npm on PATH). Maintenance resolution now detects shims under the default ProgramData\chocolatey\bin path or a custom install via ChocolateyInstall, picks the sibling choco.exe, and exposes choco upgrade <package> --yes with lock key chocolatey instead of npm/Homebrew updaters.

Adds optional chocolateyPackageName on package-managed provider definitions; OpenCode sets it to opencode. Providers without a Chocolatey name still fall back to manual-only when a shim is detected. Command lookup env now includes ChocolateyInstall. Regression tests cover default and custom Chocolatey layouts on win32.

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

Note

Add Chocolatey update support for OpenCode on Windows

• Adds chocolateyPackageName to PackageManagedProviderMaintenanceDefinition and sets it to opencode for the OpenCode provider so Chocolatey installs can self-update
• Adds resolveChocolateyUpdateExecutable which detects binaries under the default Chocolatey bin directory or a ChocolateyInstall-derived path, then resolves the sibling choco.exe
• Adds Chocolatey capability resolution after existing pnpm, npm, and Homebrew checks in resolvePackageManagedProviderMaintenance; definitions without a Chocolatey package name fall back to manual-only
• Behavioral Change: CommandLookupEnvConfig now carries an optional ChocolateyInstall value; providers without chocolateyPackageName are unaffected and existing package-manager precedence is preserved

^{Macroscope summarized 5438ac4.}

[macroscopeapp]

Approvability

Verdict: Approved at d9d5eaa

Macroscope's review found this PR approvable — This is a localized server-side fix that makes the existing provider update action target Chocolatey-managed OpenCode installations instead of an unrelated npm installation. Its runtime impact is narrowly scoped, covered by regression tests, and introduces no schema, deployment, security, billing, or authentication changes.

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

[juliusmarminge]

Thanks for the PR. We're not taking changes to the orchestration and provider layers right now: that part of the server is being rewritten for V2, and merging into the current code would either conflict with or be thrown away by that work.

Closing for now. If this is still an issue once V2 lands, please reopen (or open a fresh PR against the new code) and we'll take a proper look.