can1357/oh-my-pi · error · Error

${formatVerificationFailure(verification, release.version)};

Error message

${formatVerificationFailure(verification, release.version)}; reinstall with: ${installerHint()}

What it means

Thrown at the end of the rename migration when, even after a repair reinstall attempt, `steps.verify()` still reports the installed version doesn't match the released version. The message pairs the verification failure with a concrete `installerHint()` command so the user can fix the install manually.

Source

Thrown at packages/coding-agent/src/cli/update-cli.ts:1502

			`install of ${release.packages.pkg} failed with exit code ${installExit}; the existing install was left untouched`,
		);
	}

	const removeExit = await steps.removeOld();
	if (removeExit !== 0) {
		console.log(chalk.yellow(`Warning: could not remove the old ${PACKAGE} package; remove it manually later.`));
	}

	let verification = await steps.verify();
	if (!verification.ok) {
		// Removing the old package may have taken the shared bin link with it;
		// reinstalling the new package restores the link.
		if ((await steps.install()) === 0) {
			verification = await steps.verify();
		}
	}
	if (!verification.ok) {
		throw new Error(
			`${formatVerificationFailure(verification, release.version)}; reinstall with: ${installerHint()}`,
		);
	}
	printVerifiedVersion(release.version);
}

/**
 * Update via package manager.
 *
 * Returns the PATH-resolved launcher check so the caller can repair a launcher
 * the manager left unusable, or `undefined` when a rename migration already
 * verified and reported its own result.
 */
async function updateViaBun(release: ReleaseInfo): Promise<InstalledVersionVerification | undefined> {
	console.log(chalk.dim("Updating via bun..."));
	let verification: InstalledVersionVerification | undefined;
	if (release.packages.pkg !== PACKAGE) {
		await migrateRenamedInstall(release, packageManagerMigrationSteps("bun", release));

View on GitHub (pinned to 9690622007)

Solutions

Run the printed installer command from the message to reinstall cleanly
Check which binary is on PATH: `which omp` / `where omp` and remove stale shims from the old package
Uninstall both old and new package names, then install the new one once: npm uninstall -g <old> <new> && npm install -g <new>
Align npm/bun global prefixes so install and PATH agree, then re-run `omp update`

Example fix

// before: stale shim from the old package name shadows the new install
$ which omp
/usr/local/bin/omp  # old install
// after
npm uninstall -g <old-pkg> && npm install -g <new-pkg>
hash -r  # clear shell command cache
omp --version

Defensive patterns

Strategy: fallback

Validate before calling

# confirm which install is actually on PATH before/after migrating
which omp && omp --version
npm ls -g --depth=0 | grep -E 'old-pkg|new-pkg'

Try / catch

try {
  await runUpdate();
} catch (err) {
  if (String(err?.message).includes("reinstall with:")) {
    // follow the embedded installerHint() command, then re-verify
    console.error(err.message);
    return;
  }
  throw err;
}

Prevention

Remove the old package name after a rename migration to avoid stale shims
Keep a single package manager owning the global install (npm or bun, not both)
Run `hash -r` (or restart the shell) after global installs so PATH resolution refreshes
Compare `npm config get prefix` with the directory of the binary on PATH

When it happens

Trigger: After migrating to the renamed package, the verification check fails; a repair pass (`steps.install()` followed by re-verify) is attempted and either the repair install fails or verification still returns {ok:false}.

Common situations: Stale global bin shim/symlink still pointing at the old package, multiple package managers (npm + bun) each having installed a copy and PATH resolving the wrong one, npm prefix mismatch between install and verification, broken PATH ordering.

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/4887e77844b69403. Report an issue: GitHub.