Skip to content

Setting to disable silent install-on-quit after an update has downloaded (autoInstallOnAppQuit) #1460

Description

@xlurie

Labels (suggested): enhancement

Is your feature request related to a problem? Please describe.

Once OpenWhispr has downloaded an available update, it installs that update automatically the next time
the app quits — with no confirmation prompt, no visible "installing update..." step, and no way to decline
or postpone at that moment. The only way to avoid it is to never let the app fully quit, which isn't
realistic for a tray/background app across reboots, sleep, or routine restarts.

For anyone running a locally-configured setup — self-hosted STT/LLM endpoints, custom prompts, specific
model settings, or just a version that's known to work well for them — this means the app can change
version out from under you without any notice, and you find out only when something that used to work
doesn't anymore.

This happened to me concretely. I run OpenWhispr fully self-hosted (local transcription + local
cleanup endpoints, validated against a specific app version). At some point the app silently reinstalled
itself on quit to a newer version. I didn't see any prompt, dialog, or notification for the install step
itself — the version had simply changed the next time I opened it. I didn't notice for well over a week,
because nothing in the UI flagged that a version change had happened; I only found out when I went looking
for something else and checked the version number. For that entire window I was running a version I had
never explicitly agreed to run, with no record of when or why it changed.

The download step and the notification-of-availability step are both reasonable and already covered by
existing preferences (#943 added a way to silence the "update available" notification). The install step
is the one with no user-facing control at all.

Describe the solution you'd like

Add a setting (Settings → General, near the existing update-notification preference) that controls what
happens after a download completes, independent of whether update checks/notifications are
enabled. Something like three levels:

  1. Auto (current default, unchanged) — download available updates, install silently on next quit.
    Existing behavior, nothing changes for users who don't touch the setting.
  2. Download only, ask before installing — download in the background as today, but keep
    autoInstallOnAppQuit off; show a clear prompt/banner ("Update to vX.Y.Z ready — Install & Restart /
    Later") that the user has to act on, instead of installing unattended on quit.
  3. Notify only, no auto-download — flip autoDownload off too, for fully manual control (useful on
    metered connections or when someone wants to review release notes before even fetching the binary).

Even shipping just option 2 (a single "Install updates automatically" checkbox, default ON) would close
the actual gap — the rest is a nice-to-have.

Implementation sketch

The updater already exposes exactly the right seams (src/updater.js, electron-updater-based):

autoUpdater.autoDownload = <preference>;          // currently hardcoded false
autoUpdater.autoInstallOnAppQuit = <preference>;   // currently hardcoded true

Both are read once in setupAutoUpdater(). Wiring a persisted preference (same store the notification
toggle already uses) in and reading it before these two assignments — plus re-reading it if settings can
change at runtime without restart — should be close to the whole change. The existing update-downloaded
IPC event already reaches the renderer, so a "ready to install" banner can reuse it directly when
autoInstallOnAppQuit is off.

Additional context

  • Prior art: This tool needs an auto update, option box, in the settings. #943 asked for update control and got a notification-visibility toggle in v1.7.3 — useful,
    but it only silences the "update available" popup. It doesn't touch autoDownload or
    autoInstallOnAppQuit, so the silent-install-on-quit behavior this issue is about was untouched by that
    fix. Allow disabling notifications #763 is the same shape (notification preferences, not install behavior).
  • Default staying ON means zero behavior change for the overwhelming majority of users who like
    install-and-forget — this is purely additive for people who need predictability: self-hosted/offline
    setups, enterprise change-control, anyone validating a specific version before rolling forward, and
    metered-connection users (via the autoDownload half).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions