Windows auto-update stopped preserving custom install directory and reinstalls to %LocalAppData%\\Programs

[szsnzz]

Description

On Windows, OpenCode desktop auto-update no longer preserves the original custom install directory.

My original installation was a machine-wide install at:

D:\OpenCode

This worked correctly for earlier updates. But in the last few days, auto-update started launching the downloaded installer and installing a new copy under:

C:\Users\<user>\AppData\Local\Programs\@opencode-aidesktop

As a result, I now have two installs:

• old install: D:\OpenCode
• new per-user install: %LocalAppData%\Programs\@opencode-aidesktop

The new desktop/start-menu shortcuts were also recreated to point to the %LocalAppData% install.

Expected behavior

Auto-update should preserve the existing install location (D:\OpenCode), or at minimum preserve the existing installation mode/location instead of silently switching from machine-wide/custom-dir install to per-user install in %LocalAppData%\Programs.

Actual behavior

Recent updates are performed by running the cached installer, and the install location switches to %LocalAppData%\Programs\@opencode-aidesktop.

Timeline

My local evidence suggests this regression started between May 10 and May 11, 2026.

Previously working

• 2026-05-08 15:19
• D:\OpenCode was updated successfully
• version became 1.14.41

First signs of failure

On 2026-05-10, updater attempted to install 1.14.46 multiple times:

• 2026-05-10 19:52:15
• 2026-05-10 20:18:21
• 2026-05-10 20:23:23

But after restart, app still reported:

• version: 1.14.41

Wrong-location install actually happens

On 2026-05-11 13:18:17, updater executed:
C:\Users\<user>\AppData\Local\@opencode-aidesktop-updater\pending\opencode-desktop-win-x64.exe --updated --force-run

After that:

• %LocalAppData%\Programs\@opencode-aidesktop\OpenCode.exe became 1.14.48
• D:\OpenCode\OpenCode.exe remained 1.14.41
• desktop/start-menu shortcuts for current user were recreated and now point to %LocalAppData%\Programs\@opencode-aidesktop

Relevant logs

main.log repeatedly shows:

• disableWebInstaller is set to false
• Install on explicit quitAndInstall
• Executing: C:\Users\<user>\AppData\Local\@opencode-aidesktop-updater\pending\opencode-desktop-win-x64.exe with args: --updated,--force-run

Example from 2026-05-11:

[2026-05-11 13:18:11.977] [info]  installing downloaded update { version: '1.14.48' }
[2026-05-11 13:18:17.980] [info]  Install on explicit quitAndInstall
[2026-05-11 13:18:17.982] [info]  Executing: C:\Users\<user>\AppData\Local\@opencode-aidesktop-updater\pending\opencode-desktop-win-x64.exe with args: --updated,--force-run

Additional context

I checked the public Electron builder config in the repo and noticed Windows uses NSIS with:

• oneClick: false
• allowToChangeInstallationDirectory: true

I did not see obvious logic to force reuse of the previous machine-wide/custom install path during auto-update.

This looks like a regression where auto-update now switches installation mode/location instead of preserving the existing install.

Environment

• OS: Windows
• Original install location: D:\OpenCode
• New unexpected install location: %LocalAppData%\Programs\@opencode-aidesktop

[Astro-Han]

The give-away in your logs is --force-run plus the pending installer being executed from %LocalAppData%\...-updater\pending\. That's electron-updater's NsisUpdater handing the downloaded NSIS installer back to itself, and with oneClick: false + allowToChangeInstallationDirectory: true the installer decides the target dir from the NSIS install state, not from where the running app currently lives.

The relevant detail: a machine-wide install at D:\OpenCode writes its InstallLocation under HKLM\...�ninstall\{guid}, while the auto-update installer being run is a per-user package, which looks up (or creates) state under HKCU instead. When the HKCU key doesn't exist, NSIS falls back to its default $LOCALAPPDATA\Programs\<appId>. So it's not that the updater "forgot" the path, it's that the per-user updater never reads the per-machine InstallLocation to begin with. The two installs you see are exactly that HKLM vs HKCU split.

This usually shows up after a switch from a perMachine to a perUser build, or after perMachine stopped being set on the published target, which lines up with your May 10-11 regression window. Worth diffing the electron-builder nsis block (perMachine, packElevateHelper) across the 1.14.41 to 1.14.46 releases. If perMachine was dropped, every existing D:\ install will get orphaned on the next update for exactly this reason.
We hit the same perMachine vs perUser landmine when building PawWork's NSIS target — the fix was pinning perMachine: true and shipping packElevateHelper: true unconditionally, so the updater always reads from HKLM and never creates a shadow per-user install.

[JustSidus]

PR #30242 solves this by switching from oneClick: true to false and enabling allowToChangeInstallationDirectory. This lets users choose where to install instead of being forced into %LocalAppData%. The perMachine vs perUser issue causing duplicate installations would be resolved.