* Accept the fifth Hermes desktop launch option
Hermes now returns five values from _desktop_launch_options(), appending the renderer accessibility switch. The launcher unpacked exactly four, so once a user's runtime updated, every launch died with "too many values to unpack" before the app opened. The launcher now takes the first four and reads the fifth when present, so it keeps working with the packaged release and with newer runtimes, and it bridges an explicit accessibility opt-out the same way Hermes' own launcher does. The launch check now also runs a five-value helper, which fails against the previous launcher.
Fixesbasecamp/omarchy#13491
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* hermes-desktop: launch against the installed runtime, accept the helper's new arity
_desktop_launch_options() returns five values since Hermes grew a trailing
renderer_accessibility field, so the launcher died with "too many values to
unpack (expected 4)" before os.execve — and gtk-launch discards stderr, so the
app icon became a silent no-op that left no process and no log line behind.
The launcher also exported HERMES_DESKTOP_IGNORE_EXISTING=1 unconditionally
while preferring the runtime's own app binary a few lines above it: with a
runtime installed, Desktop skipped that runtime and offered first-run setup
instead of the user's sessions. Ignoring an existing runtime is only correct for
the bundled /opt app, which is built from the package's release commit and
cannot drive a runtime built from another one.
pkgrel bumped for the changed artifact.
* Tell only the packaged Hermes Desktop to skip an existing install
The runtime's own app now finds its runtime the way `hermes desktop` launches it, through the installed-runtime lookup, instead of being pinned to it with HERMES_DESKTOP_HERMES_ROOT. That variable is upstream's developer override: it resolves before the lookup that Repair install bypasses, so pinning the runtime turned a hard repair into a restart against the same broken venv. HERMES_DESKTOP_IGNORE_EXISTING is set only when the launcher falls back to the packaged /opt app, and an explicit value in the environment still wins, so the in-app updater's relaunch of the runtime app no longer inherits it.
The fifth launch option is read the way it was accepted in the previous commit but one, with the checksums the two earlier commits left stale brought up to date. runtime-test.py now records both variables, so it fails if the unconditional export or the root pin comes back.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: manuaudio <manu@arimaka.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Omni <omni@omninova.com.mx>
Co-authored-by: Codex XHigh <noreply@openai.com>
