fix(opencode): share user installation with terminal clients - #756
Conversation
|
Post-rebase validation for commit 461e895: both server/UI TypeScript checks PASS; 31 targeted server tests PASS; 13 real-component Chromium setup/settings tests PASS; isolated native Windows npm installation, terminal launcher repair and mapped-executable preservation PASS; git diff --check PASS. Dependencies installed from the rebased lockfile (OpenCode client 2.0.15). Independent gatekeeper review is in progress before the requested administrator merge. |
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Independent gatekeeper review
Verdict: CHANGES REQUIRED
Reviewed exact HEAD 461e895 against upstream/dev ea3aeb9 (also the merge base). The worktree was clean before and after review. This is an independent COMMENT review, not an approval, and no source/branch changes or merge were performed.
Finding
[P2] Preserve automatic recovery for official historical npm installations — packages/server/src/opencode-update/shared-installation.ts:70-78 (related discovery at 42-46 and version admission at 101-103). The installation identity check assumes every official npm launcher resolves directly to bin/opencode.exe. Published V2 packages do not all have that layout. With a real isolated npm global installation of @opencode/[email protected], the manifest points opencode2 to bin/opencode2.exe: PATH discovery and the real Windows version probe succeed, but sharedInstallPrefix() returns undefined. Production OpenCodeUpdateService.getStatus() consequently returns state=update_required, updateAvailable=true, canUpgrade=false. The normal automatic selection can no longer upgrade this known-incompatible npm installation. A current private fallback does not help because PATH now wins. @opencode/[email protected] exposes another official transition layout: the preferred opencode2.cjs only prints that the command was renamed and exits 1, while opencode points at the actual executable; discovery selects the retired launcher, resulting in state=error and no install action. The same fixture using 2.0.3 is correctly recognized as upgradeable. Please recognize the verified historical package/bin layouts, select the usable native command for the rename-transition package, and allow ordered known-beta-to-stable migration while retaining refusal of unorderable custom labels and non-npm/custom installations. Cover the real manifest/launcher shapes rather than only injecting upgradeBinary in service tests.
Independent validation performed
- Read applicable AGENTS.md and all 42 changed files; traced discovery through BinaryResolver, settings validation, updater/service actions, manager path resolution, host/WSL spawn/lifecycle handling, and setup UI/store/i18n. Reviewed shared-prefix locking, Windows mapped-executable preflight, npm launcher verification, migration/repair/no-downgrade behavior, shell registration and error paths.
- Installed actual published npm packages 0.0.0-beta-19275, 2.0.0, and 2.0.3 into three fresh synthetic Windows-user prefixes. Exercised production
resolveDefaultInstallation,sharedInstallPrefix, realprobeBinaryVersionAsync, andOpenCodeUpdateService.getStatus()with a fixed latest-version resolver and no lifecycle callback. Confirmed the two historical-layout failures above and the 2.0.3 positive control. Reproduction script:pr756-independent-review.mjsin the approved temporary opencode directory; retained results:pr756-gatekeeper-Ty90pJ/results.json. - Exercised production
registerUserPathagainst synthetic profiles, then sourced generated profiles twice in real Bash and POSIX sh under Ubuntu/WSL using an empty environment and explicit fixture paths. Existing content, idempotence, spaces, apostrophes, literal dollar signs and glob characters were preserved. Both checks passed. Script:pr756-shell-review.mjs; fixture:pr756-shell-o8FdBK. git diff --check upstream/dev...HEADpassed. Verified remote PR head matches the reviewed SHA.
Factual limits
The principal agent is running the post-rebase typechecks, full server suite, browser suite and current-version native Windows npm fixture; this review does not claim those results. No macOS runtime, actual zsh/fish process, Windows registry write/broadcast, or live host/WSL daemon lifecycle was exercised in this review. No real user PATH/profile, shared OpenCode daemon, or user database was changed. Native reproduction only installed into synthetic temporary homes and issued --version; it never issued a service command.
One actionable finding remains; this SHA does not pass the zero-finding merge gate.
| const manifest = JSON.parse(readFileSync(path.join(path.dirname(binary), "..", "package.json"), "utf8")) | ||
| if (manifest.name !== "@opencode/cli") return undefined | ||
| const resolved = platform === "win32" ? buildSpawnSpec(command, [], { platform, env: host.env }).command : realpathSync(command) | ||
| if (realpathSync(resolved) !== realpathSync(binary)) return undefined |
There was a problem hiding this comment.
[P2] Official historical npm installations fail this identity check. Reproduced with a real isolated npm install --global --prefix <fixture> @opencode/[email protected]: its manifest/launcher targets bin/opencode2.exe, so discovery and --version work but this comparison makes sharedInstallPrefix() undefined and setup reports update_required with canUpgrade=false. PATH now also hides any usable private fallback. Version 2.0.0 has a second official transition shape: opencode2 points at a .cjs rename notice which exits 1, while opencode points at the usable native executable; the new discovery picks the failing alias. Version 2.0.3 is a positive control and works. Please recognize/verify the historical official bin layouts, pick the usable command in the rename transition, and retain known-beta-to-stable upgrade admission (the stable-only existing-version check at 101-103 also needs to cooperate). Full native evidence and reproduction details are in the review body.
Prefer the PATH executable over legacy private CodeNomad copies and expose the actual installation source. Use bundled Node/npm to install a standard user-global package and register its terminal command directory. Keep explicit custom and WSL selections user-managed, preserve private copies for migration, and allow migration or PATH repair even without a newer release. Serialize CodeNomad installers through a per-prefix filesystem lock, recheck versions under the lock, verify the published launcher, and avoid downgrading newer installations. Defer Windows updates before npm touches a mapped or non-writable executable; never stop the shared daemon to install. Report localized installation conflicts and retain explicit service activation. Present recovery diagnosis and installation before executable selection, while preferences retain executable-first inline controls and logs last. Keep effective version metadata synchronized and translate provenance, migration, and conflict feedback in every locale. Validated with 31 server regressions, 13 real-component browser scenarios, UI/server typechecks, and an isolated native Windows npm install covering terminal discovery, missing-launcher repair, and a live executable lock. Document migration, PATH registration, installer locking, cleanup, and platform limitations.
Read the package's published bin map and verify the real launcher target before choosing the automatic command. This avoids the retired opencode2.cjs alias in 2.0.0 and accepts beta installations that published opencode2.exe, so existing users can migrate to a common stable installation. Probe and preflight the historical executable while replacing the package; allow known beta versions to upgrade without downgrading current stable installs. Regress historical launcher fixtures and confirm real beta/2.0.0 npm installations migrate to 2.0.7 in isolated temporary prefixes without touching the shared daemon or real PATH.
461e895 to
c6a4b25
Compare
|
Correction du finding gatekeeper sur le SHA c6a4b25 : le �in officiel et la cible réelle du lanceur sont vérifiés ; 2.0.0 choisit opencode.cmd à la place de l'alias opencode2.cjs, et la bêta reconnaît opencode2.exe. Les installations npm réelles isolées |
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Independent gatekeeper review — follow-up
Verdict: CHANGES REQUIRED
Exact reviewed HEAD: c6a4b25. Base: upstream/dev e25fd8d. Reviewed the correction and resulting PR diff, including its integration with the rebased upstream. Worktree remained clean; no source/branch changes or merge.
Previous finding: corrected
The historical official npm launcher finding from the previous independent review is closed. I independently exercised production discovery, real executable probing, OpenCodeUpdateService.upgrade() and installSharedOpenCode() with real isolated npm packages. Both 0.0.0-beta-19275 → 2.0.7 and 2.0.0 → 2.0.7 now succeed, expose upgrade admission before installation, and produce the same 2.0.7 version through backend discovery and the terminal command. No daemon/service call was made; PATH registration was replaced with an assertion-only fixture callback.
New findings
-
[P2] Preserve the actual PATH executable when an npm package also exists in that directory —
packages/server/src/opencode-update/shared-installation.ts:68-72. The new package-first early return bypasses the executable candidates and PATHEXT precedence. Native Windows reproduction: install the official npm 2.0.3 package into a fixture prefix, place a real standalone OpenCode 2.0.7 at<prefix>/opencode2.exe, and put that prefix first on PATH.cmd /c opencode2 --versionresolves the .exe and reports 2.0.7, butfindPathOpenCode()now selects<prefix>/opencode2.cmd, the backend reports 2.0.3, andsharedInstallPrefix()still declares it npm-upgradeable. Before this correction, the .exe won and was correctly classified as non-npm. This breaks the core shared-terminal-installation/standalone-preservation contract. Keep normal PATH/PATHEXT authority; the historical.cjsrename-alias exception should apply to the verified alias actually encountered, not give an adjacent package precedence over another executable. The same scan also derives a POSIX prefix from every PATH directory without requiring it to be that prefix's bin directory: for example/usr/local/sbincan cause it to return/usr/local/bin/opencode2before reaching a later actual PATH candidate. Bound package recognition to the command directory being scanned. -
[P2] Make the historical launcher regression fixture platform-correct —
packages/server/src/opencode-update/shared-installation.test.ts:120-132. The new test unconditionally creates<prefix>/node_modules/..., Windows.cmdlaunchers and PATH=prefix, while production runs in the native platform mode. Linux/macOS expect<prefix>/lib/node_modules/..., executable/symlink commands under<prefix>/binand PATH pointing to that bin directory. Both exact-head CI compatibility jobs fail at line 133 with actualopencode2versus expected<temp>/.../opencode2.cmd; this prevents the later native compatibility validations from running. Use platform-appropriate package layout, command names, permissions and links (as the existing npmFixture already does), and actually exercise both historical layouts on POSIX rather than silently skipping them. Evidence: Ubuntu job, macOS job. I read the completed job logs and verified that they checked out this exact SHA.
Validation/evidence
- Independent real Windows historical migrations described above: both passed.
- Independent native Windows PATH precedence reproduction described above: confirmed the backend/terminal mismatch using real official OpenCode executables, not mocked version output.
- Local targeted production tests: 28/28 passed (
shared-installation.test.ts,service.test.ts, routeopencode-update.test.ts) on Windows. - Exact-head Ubuntu/macOS CI logs independently confirm the new test failure.
git diff --check upstream/dev...HEADpassed. Local and remote PR SHA matched.- Local reproduction: approved temporary
opencode/pr756-rereview.mjs; retained JSON:opencode/pr756-gatekeeper-Ty90pJ/rereview-c6a4b258.json.
Limits: I did not repeat full suites or live desktop/daemon acceptance, write the real registry/PATH/profiles, or run a native POSIX npm migration in this follow-up. The POSIX sibling-directory issue above is a source-traced consequence; the Windows precedence mismatch and historical migrations were executed natively.
The original finding is resolved; two new actionable findings remain, so this SHA does not meet the zero-finding merge gate.
| if (!directory || !path.isAbsolute(directory)) continue | ||
| const prefix = platform === "win32" ? directory : path.dirname(directory) | ||
| if (npmPackage(prefix, platform)) { | ||
| const published = npmCommand(prefix, platform) |
There was a problem hiding this comment.
[P2] This package-first return bypasses actual PATH/PATHEXT precedence. Reproduced natively: npm @opencode/[email protected] in a temp prefix plus a real standalone 2.0.7 at prefix/opencode2.exe. The terminal selects .exe and reports 2.0.7, but discovery selects .cmd, reports 2.0.3 and declares the prefix npm-upgradeable. The previous code respected .exe precedence and retained non-npm authority. Restrict historical alias handling to the verified alias actually encountered; do not override a standalone command just because its directory contains an npm manifest. On POSIX also require the scanned directory to be the actual npm command directory, otherwise a PATH entry such as /usr/local/sbin can return a command from sibling /usr/local/bin. Full reproduction is in the review body.
| await writeFile(path.join(path.dirname(binary), "..", "package.json"), JSON.stringify({ name: "@opencode/cli", bin: { | ||
| opencode2: name === "opencode2" ? `./bin/${oldBinary}` : "./bin/opencode2.cjs", opencode: "./bin/opencode.exe", | ||
| } })) | ||
| const command = path.join(prefix, `${name}.cmd`) |
There was a problem hiding this comment.
[P2] This fixture is Windows-only but the test runs on Linux/macOS too: it hardcodes the Windows node_modules layout, .cmd commands, and prefix itself as PATH. Exact-head Ubuntu and macOS compatibility jobs both fail the assertion at line 133 (actual bare opencode2 versus expected fixture .cmd). Use native platform layout/permissions/symlinks and npmCommandDirectory for PATH, preserving POSIX coverage of the historical launchers. Links and confirmed CI log details are in the review body.
Discover commands in actual PATH/PATHEXT order rather than giving a package's npm shim implicit priority over a standalone executable in the same directory. Verify npm launcher identity only when that shim is the selected command; POSIX sibling directories cannot borrow a prefix's package metadata. Make historical launcher fixtures portable across Windows, Linux and macOS, cover same-prefix standalone precedence and neighboring POSIX directories, and retain native Windows migration and bundled npm installation checks. Validation: 33 targeted server tests, server typecheck, isolated npm Windows fixture and diff check.
|
La deuxième contre-revue est traitée sur ef52ea0 : priorité réelle PATH/PATHEXT préservée lorsqu'un exécutable autonome partage le préfixe npm ; validation d'identité seulement pour le lanceur npm choisi ; répertoire �in POSIX strictement vérifié. Fixtures historiques portables Windows/Linux/macOS et tests ajoutés pour la priorité d'un exécutable autonome et les répertoires POSIX voisins. 33 tests serveur ciblés, typecheck serveur, installation native Windows isolée et diff-check passent. Nouvelle revue gatekeeper indépendante sur ce SHA demandée. Les deux échecs de la CI initiale concernent les tests system-messages inchangés, reproduits localement hors de ce diff ; je n'attends pas la CI pour la boucle gatekeeper. |
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Independent gatekeeper review — follow-up
Verdict: CHANGES REQUIRED
Reviewed exact HEAD ef52ea0, against upstream/dev e25fd8d. Local and remote PR SHA match; worktree is clean. No source/branch changes or merge.
Disposition of previous findings
Follow-up to the c6a4b258 independent review:
- Historical test portability: CLOSED. I ran the actual checked-in
shared-installation.test.tsusing native Linux Node 24.20.0 under Ubuntu/WSL, with a temporary Linux esbuild executable and temporary fixture root: 8/8 passed, including historical npm layouts and symlinks. No simulated process.platform or rewritten tests were used. - PATH precedence: PARTIALLY FIXED. Native Windows same-prefix
.exeprecedence now passes using actual OpenCode 2.0.7 and npm 2.0.3 executables: both terminal and backend select 2.0.7, and automatic npm update is refused. The POSIX sibling-directory case also passes a native Linux reproduction. However, the same-prefix standalone case remains broken on POSIX as detailed below.
Remaining finding
[P2] Keep a standalone POSIX executable selectable when npm provenance verification fails — packages/server/src/opencode-update/shared-installation.ts:81-83. The new guard still skips every executable in a POSIX npm bin directory when npmLauncher() fails. Failure to prove npm provenance is not proof that the executable should be skipped. This discards a valid standalone opencode2 whenever the prefix still has an @opencode/cli manifest, then selects another npm alias or a fallback instead.
Executed reproduction, using real Linux packages/binaries:
- Install official
@opencode/[email protected]into a fresh synthetic prefix. - Obtain an official Linux 2.0.7 executable in another isolated prefix; replace the first prefix's
bin/opencode2symlink with a standalone copy of that executable. Leavebin/opencodeand the 2.0.3 package intact. - Set the fixture PATH to the first prefix's
bin, then compare the real terminal invocation with production discovery. opencode2 --versionreports opencode v2.0.7.findPathOpenCode()instead returns<prefix>/bin/opencode, the backend probe reports 2.0.3, andsharedInstallPrefix()incorrectly returns that npm prefix as upgradeable.
Please preserve this standalone candidate as a user-managed PATH executable. Only bypass the specific verified historical rename-notice launcher; do not use generic failed npm verification as a reason to ignore an executable. Add a real same-prefix POSIX case: the new test's POSIX branch currently checks only a sibling directory, so it does not exercise the behavior covered by the Windows branch.
Independent validation
- Native Windows same-prefix precedence reproduction: PASS; no npm upgrade authority for standalone .exe.
- Native Linux same-prefix precedence reproduction with actual official executables: FAIL, as above.
- Native Linux POSIX sibling-directory reproduction: PASS.
- Native Linux checked-in shared-installation suite: 8/8 PASS, including historical fixture portability, locks, repair and profile fixture tests.
- Windows targeted shared-installation, updater service and update routes: 29/29 PASS.
git diff --check upstream/dev...HEAD: PASS.
Evidence under the approved temporary opencode directory: pr756-windows-ef52ea0c.mjs, pr756-linux-review/precedence.mjs, and pr756-linux-review/native-AJJyZX/results-ef52ea0c.json. All npm installations, executables and profile files were confined to synthetic temporary homes. The real user PATH/profiles/registry and the shared OpenCode daemon were untouched. No service command was issued.
Limits: native Linux was exercised through WSL; macOS itself and live desktop/daemon behavior were not rerun. Full CI completion is a separate result.
One actionable finding remains. This SHA does not satisfy the zero-finding merge gate.
| if (!statSync(candidate).isFile()) continue | ||
| accessSync(candidate, platform === "win32" ? constants.F_OK : constants.X_OK) | ||
| if (inNpmBin && npmPackage(prefix, platform) && (platform !== "win32" || extension === ".cmd")) { | ||
| if (!npmLauncher(candidate, prefix, platform)) continue |
There was a problem hiding this comment.
[P2] This continues to discard standalone POSIX executables sharing an npm bin directory. Native Linux repro with real packages: install npm 2.0.3, replace bin/opencode2's symlink with a standalone official 2.0.7 executable, leave npm's bin/opencode intact, and put bin first on PATH. Terminal opencode2 reports 2.0.7; discovery skips it because npmLauncher() fails, selects bin/opencode (2.0.3), and incorrectly allows npm updates. Failed npm provenance should retain the candidate as user-managed. Only bypass the specifically verified historical rename-notice alias. The new POSIX test only covers a sibling directory, not this same-prefix replacement. Full executed evidence is in the review body.
Only skip an OpenCode command when it actually resolves to the package's retired .cjs alias. A replaced POSIX npm symlink can be an independently installed, newer executable; keep terminal PATH order and classify it as user-managed rather than selecting the other npm shim and offering an unsafe npm update. Expand same-prefix precedence coverage for POSIX alongside Windows and document the supported launcher transition. Verify targeted server tests, server typecheck, isolated native Windows npm installation and diff integrity.
|
Troisième finding gatekeeper corrigé sur 5ce224a : sous POSIX, un exécutable autonome qui remplace le lien npm �in/opencode2 garde la priorité PATH et reste géré par l'utilisateur ; seul un lien qui pointe réellement vers l'ancien alias .cjs est ignoré. Régression de précédence étendue, 33 tests serveur ciblés, typecheck serveur et fixture native Windows passent. Contre-revue Linux indépendante demandée sur ce SHA. La fusion administrateur suivra le verdict zéro finding, sans attendre la CI. |
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Independent gatekeeper review — follow-up
Verdict: CHANGES REQUIRED
Exact reviewed HEAD: 5ce224a; base upstream/dev: e25fd8d. Local and remote head match. Worktree remained clean; no source/branch modification or merge.
Previous POSIX finding: CLOSED
The last finding from review ef52ea0c is resolved. I reused the real isolated Linux fixture containing npm OpenCode 2.0.3 and a standalone official 2.0.7 replacing bin/opencode2. Native Linux discovery and terminal now both select 2.0.7, sharedInstallPrefix() returns undefined, and an attempted installSharedOpenCode() is refused before installation/PATH registration. Native Linux historical/symlink tests still pass.
Remaining actionable finding
[P2] Apply the verified-retired-alias exception to Windows .cmd launchers too — packages/server/src/opencode-update/shared-installation.ts:91. The POSIX branch now skips only a proved retired alias, but the Windows condition still skips every .cmd candidate that fails npm executable verification. A user-owned wrapper is a valid PATH command, not evidence that discovery should advance to npm's other alias.
Native Windows reproduction with real OpenCode executables:
- In an isolated prefix containing official npm 2.0.3, retain
opencode.cmdand the package. - Replace
opencode2.cmdwith a valid user wrapper:@echo offfollowed by"%~dp0\standalone-opencode.exe" %*, where that sibling standalone executable is official OpenCode 2.0.7. - Put the prefix first on the fixture PATH.
- Both the real terminal
opencode2 --versionand a direct production probe ofopencode2.cmdreport 2.0.7. ButfindPathOpenCode()discards that command, selectsopencode.cmd, reports 2.0.3, andsharedInstallPrefix()incorrectly authorizes npm updates.
Preserve unknown/custom .cmd commands in PATH order and classify them as user-managed. Skip only the positively identified historical rename-notice wrapper, while keeping real npm 2.0.0 recovery working. Add the Windows custom-wrapper counterpart to the same-prefix regression. This is an additional uncovered instance of the PATH-authority defect, not a failure of the now-corrected POSIX reproduction.
Validation
- Real Linux standalone replacement reproduction: PASS, including refusal of automatic npm update.
- Checked-in shared-installation suite under native Ubuntu/WSL Node 24.20.0: 8/8 PASS.
- Windows shared-installation, service and update-route suites: 29/29 PASS.
- New Windows custom
.cmdreproduction: confirmed backend/terminal mismatch as above. git diff --check upstream/dev...HEAD: PASS.
Evidence scripts in the approved temporary opencode directory: pr756-linux-review/verify-5ce224ad.mjs and pr756-windows-wrapper-review.mjs. The Windows fixture wrapper was restored after the test. Only temporary synthetic installations/files were touched; no real user PATH/profile/registry, shared daemon or database was changed, and no service command was issued.
Limits: macOS runtime and full desktop/daemon acceptance were not rerun; native Linux and Windows were exercised as described.
One actionable finding remains; this SHA does not satisfy the zero-finding merge gate.
| try { | ||
| if (!statSync(candidate).isFile()) continue | ||
| accessSync(candidate, platform === "win32" ? constants.F_OK : constants.X_OK) | ||
| if (inNpmBin && npmPackage(prefix, platform)) { |
There was a problem hiding this comment.
[P2] Windows still discards every custom .cmd command in an npm prefix when npmLauncher() fails. Reproduced natively with npm 2.0.3 plus opencode2.cmd pointing to an official standalone 2.0.7 executable: terminal and direct probe report 2.0.7, but discovery skips the wrapper, selects npm opencode.cmd (2.0.3), and authorizes npm updates. Preserve custom wrappers as user-managed PATH commands; skip only a positively verified historical rename-notice wrapper, just as the corrected POSIX branch does. Full actual-binary reproduction is in the review body.
Treat a Windows npm-prefix command as the retired rename alias only when its package manifest advertises the .cjs entry and its bounded command script positively invokes that entry. Respect a customized opencode2.cmd in PATH instead of silently falling through to the older opencode.cmd shim or authorizing npm to replace it. Use a representative historical .cjs command fixture, add a regression for a custom Windows wrapper alongside an npm alias, and document the selection boundary. Targeted tests, server typecheck, native Windows installation and diff integrity pass.
|
Quatrième finding gatekeeper traité sur e33a6a1 : seul le vrai script npm invoquant l'alias historique .cjs publié dans le manifeste est écarté ; un .cmd personnalisé dans le même préfixe reste prioritaire dans le PATH et non géré par npm. La fixture historique Windows reproduit désormais le véritable script de renommage, avec une régression dédiée pour le wrapper autonome. 34 tests serveur ciblés, typecheck, fixture native Windows et diff-check passent ; branche sans conflit avec dev. Revue gatekeeper indépendante demandée sur ce SHA. La fusion admin reste conditionnée au verdict zéro finding, sans attendre la CI. |
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Independent gatekeeper review — final follow-up
Verdict: PASS — zero actionable findings
Exact reviewed HEAD: e33a6a1. Base: upstream/dev e25fd8d. Local and remote PR HEAD match. Reviewed the latest correction and its integration with the previously reviewed complete PR diff. Worktree remained clean; no source/branch changes or merge were performed. This is a COMMENT review, not an approval.
Previous finding: CLOSED
The custom Windows .cmd finding from the preceding independent review is resolved. Using the retained isolated prefix with real npm OpenCode 2.0.3, I replaced opencode2.cmd with a wrapper invoking a real standalone OpenCode 2.0.7 and kept the npm opencode.cmd alias present. Production discovery now selects the custom wrapper; both backend and terminal report 2.0.7. sharedInstallPrefix() returns undefined and installSharedOpenCode() refuses the automatic update before installer or PATH-registration mutation. The fixture wrapper was restored after the check.
Independent validation on this SHA
- Real Windows custom-wrapper precedence: PASS, including refusal of npm update authority.
- Real official npm 0.0.0-beta-19275 → 2.0.7 migration: PASS. Reinstalled the actual historical package in a synthetic prefix, exercised production discovery/probing and
OpenCodeUpdateService.upgrade()through the real installer, and verified matching backend/terminal versions. - Real official npm 2.0.0 → 2.0.7 migration: PASS, exercising its actual generated retired
.cjslauncher. The narrowed exception preserves this recovery path. - Real Linux same-prefix standalone replacement: PASS. Reused the Ubuntu/WSL fixture with npm 2.0.3 and standalone official 2.0.7 replacing
bin/opencode2; discovery and terminal select 2.0.7 and automatic npm installation remains refused. - Windows targeted tests: 30/30 PASS across shared installation, updater service and update routes.
- Native Linux shared-installation test file: PASS under Node 24.20.0. Node reports 9 passing tests; the Windows-only wrapper test returns early on Linux, so eight cases execute there, including historical symlink layouts, same-prefix/sibling discovery, repair, locks and synthetic shell-profile registration.
git diff --check upstream/dev...HEAD: PASS.
Audited the revised retired-alias recognition against both real historical launchers and custom-wrapper behavior, plus update admission, PATH order, native execution and the existing POSIX correction. No additional actionable findings were identified. All findings raised during this independent review loop are now closed.
Evidence is retained under the approved temporary opencode directory: pr756-verify-e33a6a16.mjs, pr756-gatekeeper-Ty90pJ/rereview-e33a6a16.json, and the Linux verification driver pr756-linux-review/verify-5ce224ad.mjs rerun against this HEAD. Only synthetic temporary installations/files were modified. No real user PATH/profile/registry, shared OpenCode daemon or user database was changed, and no service command was issued. PATH registration in native migration checks used an assertion-only fixture callback.
Factual limits
This follow-up does not claim completion of the full remote CI matrix or repeat live desktop/daemon acceptance and actual macOS execution. Those remain separate validation results owned by the principal merge workflow. The independent zero-finding review gate passes for this exact SHA.
…setup (#760) ## Summary Retire the prerelease private OpenCode installation completely as an executable source. Automatic selection now uses PATH and the conventional shared user npm installation. Existing private files are neither migrated nor deleted. - Remove the private installer, receipt reader and fallback introduced/retained by #756. - Ignore saved private selections and reject validation/launch from `~/.local/share/codenomad/opencode`, including private PATH entries. Prevent installation into that retired prefix. - Remove private-copy descriptions from all ten locales and update the runtime policy documentation. - Keep supported custom installations, native shared-service ownership/authentication and explicit restart behavior. ## Reproduction and scope The initial genuinely empty-profile test passed, but it did not match the affected machine: that machine had no Git and retained a private prerelease OpenCode copy. On the exact installed `v0.20.0-dev-20260923-baf674fc` Tauri artifact, seeding a valid private copy plus its `selected` receipt and `current` marker makes setup report `state: ready`, `installationSource: legacy`, and suppresses the missing-installation screen. The new desktop regression fails against that release with `ready !== missing`. With rebuilt server/UI resources in an isolated copy of the same Tauri host, the identical private-copy scenario reports missing, offers installation, installs the shared npm package, authenticates OpenCode 2.0.15 and resumes the requested folder without Git. This demonstrates the missing-setup cause; it does not claim to explain every initially reported startup slowdown. ## Validation - 59 targeted server tests passed: discovery/install/update, retired paths, binary selection, Windows/WSL spawn and binary validation routes. - 13 real-component setup browser tests passed. - 23 focused retirement/launch tests passed after the final network-path preflight adjustment. - UI TypeScript check passed; production server/UI/automation/pruning build passed. - Installed-release private-copy reproduction failed as expected; corrected isolated Tauri acceptance passed. - `git diff --check` passed. Desktop qualification uses isolated profiles, services and databases. The sole simulated installation side effect is HKCU PATH registration, captured by a fixture preload; bundled npm installation, package verification, native-parent service start and authenticated API checks are real. The shared user daemon and installed application were not replaced by the fix. Remote CI is pending. ## Maintenance notes Existing oversized files touched: `packages/server/src/api-types.ts` (~583 lines) and `packages/ui/src/lib/i18n/messages/*/settings.ts` (~625–639 lines). No size-only refactor is included.
1 participant
Summary
Important behavior
Installation never stops the shared OpenCode daemon. Service restart remains explicit. Windows live-executable conflicts are reported as deferred updates. Old private installation directories are not deleted. The lock coordinates CodeNomad backends, not external package managers; crash recovery is documented.
Validation
upstream/dev; post-rebase validation and independent gatekeeper review will be recorded below before merge.Maintenance notes
Existing oversized files touched:
packages/server/src/api-types.ts(~579 lines) and localepackages/ui/src/lib/i18n/messages/*/settings.ts(~626–640 lines). New modules remain small and focused.