[quickbeard]

@opencode-aidesktop was on screen. On Windows the app installed itself into %LOCALAPPDATA%\Programs\@opencode-aidesktop and kept downloaded updates in @opencode-aidesktop-updater beside it.

Neither name comes from productName. A one-click perMachine: false install takes appInfo.sanitizedName — getWindowsInstallationDirName(appInfo, !oneClick || isPerMachine) returns productFilename only when that flag is true, and for us both operands are false. updaterCacheDirName is the same string plus -updater, and it is baked into app-update.yml on every platform, so the leak was not Windows-only.

The fix

Override the derived name with extraMetadata.name instead of renaming the workspace package. DIVERGENCES keeps @opencode-ai/* package ids upstream on purpose, and that rule is still right — the package id stays @opencode-ai/desktop; only what the packager derives from it changes. extraMetadata merges into the metadata appInfo reads (packager.js:277), so this decouples the internal id from the user-visible one.

Per channel, like appId: the old value was channel-independent, so dev, beta and prod all installed over the same directory and shared one updater cache. Single-sourced with rpm.packageName — the same identity on Linux — as PACKAGE_NAMES, so the two cannot drift.

	before	after
install dir	Programs\@opencode-aidesktop (all channels)	Programs\codev / codev-beta / codev-dev
updater cache	@opencode-aidesktop-updater (all channels)	codev-updater / codev-beta-updater / codev-dev-updater

The .deb package name is not affected, despite also deriving from this name. An earlier revision of this description claimed it went CoDev → codev; that was wrong. FpmTarget passes appInfo.linuxPackageName straight to fpm, and fpm normalizes the name itself — it downcases with a warning and turns the space into a hyphen. Run against the cached fpm 1.17.0 directly:

input	resulting Package:
CoDev	codev
CoDev Beta	codev-beta
CoDev Dev	codev-dev

A prod .deb built from main before this branch confirms it: dpkg-deb -f reports Package: codev. So on the deb this change only silences an fpm warning. macOS derives nothing from the name either. Windows and the updater cache are the whole user-visible effect.

Verification

Confirmed against a real packaged build, not just by reading the source — both of these derive from sanitizedName:

• dist/win-unpacked/resources/app-update.yml now reads updaterCacheDirName: codev-updater
• the intermediate NSIS archive is codev-1.18.4-8-x64.nsis.7z, previously @opencode-aidesktop-…

Not directly observed: the install directory itself, which would mean running the installer. Its define is getWindowsInstallationDirName, a two-line pure function returning sanitizedName on this path, and the two artifacts above pin sanitizedName to codev.

electron-builder.config.test.ts covers the new name per channel. Full desktop suite: 136 pass, 1 fail — ships and re-signs the codev-vmm helper on macOS, which fails on main too (a toEndWith assertion using forward slashes against a path.join result on Windows). Untouched here.

Scope

Also updates DIVERGENCES per the fork's rule, including the Known rebrand gaps section, whose "Internal names" bullet justified keeping @opencode-ai/* as "names users never see" — no longer true for the desktop package, so the bullet now records the exception and the fix.

Rescanned the desktop package for the same shape of leak. The persisted store file names (opencode.settings, opencode.{draft,workspace,global,window,updater}.* under %APPDATA%\ai.codev.desktop) are equally visible but are not renamed here: unlike a derived name, renaming those orphans existing state and needs a migration. Deliberately untouched too, per the existing table row: the basic-auth username "opencode" (must match the server default), the Tauri app ids in migrate.ts, the ../opencode/dist build paths, and the WSL installer URL/CLI path, which are real external identifiers.

🤖 Generated with Claude Code