Update Hermes Desktop to 2026.9.7 and use normal release promotion

[spencerbull]

Update hermes-desktop from 2026.8.31-3 to 2026.9.7-1, pinning the v2026.9.7 release commit and the tarball checksum.

The release carries the namespace-sandbox change that runtime.patch used to add to scripts/desktop-update/posix.sh, and moves the desktop launch helpers out of hermes_cli/main.py into hermes_cli/main_desktop.py. runtime.patch is refreshed to upstream's text and still shipped, because Omarchy's installer refuses to run without the file and accepts an already-upstreamed patch through its reverse-apply check, so nothing is applied to a fresh 2026.9.7 runtime. runtime-test.py proves exactly that path by reverse-checking the patch against the release instead of applying it, and reads the launch option parser and its constants from main_desktop.py, which is where the launcher now finds them.

Release policy. Remove Hermes from the fast release ring. Package updates build on edge and reach rc and stable through the normal promotion pipeline, allowing the packaged release and Omarchy installer to be validated together. Users retain the existing in-app updater when they choose to move to newer upstream code.

Rollout dependency. omacom/omarchy#10846 fixes the installer's build-stamp import for the new module layout while retaining support for older releases. Ship that fix on edge before publishing this package there, then promote the compatible Omarchy installer and Hermes package together through rc and stable.

Release-policy validation: metadata validation passes; the build selector includes Hermes on edge and excludes it from automatic rc/stable builds; the promotion selector accepts both rc and stable.

Refs #262.

🤖 Reviewed by Fable 5.1 in Claude Code and Codex XHigh.

[spencerbull]

Reviewed 9c7f003 against master at b3c1ef8. This is the maintainer's own pull request, so it ran on the maintainer's own machine rather than a worker VM; no worker is configured here in any case, and everything executed came from the checksum-verified release tarball and this branch.

Checked

• The annotated tag v2026.9.7 dereferences to 2237be3…, matching _commit; the tarball and every local source match sha256sums.
• Against the release's posix.sh, git apply --check runtime.patch fails and git apply --reverse --check passes, which is the fallthrough the installer takes at bin/omarchy-install-ai-hermes:100-105. The four lines the patch carries are upstream's text verbatim, so the reverse check is exact.
• bin/build --package hermes-desktop for edge/x86_64 ran check() inside makepkg and passed. The package carries install-stamp.json with commit 2237be3… on branch main, plus install.sh, runtime.patch, chrome-sandbox at 0755 and LICENSE.electron.txt.
• _desktop_launch_options in main_desktop.py references only _LINUX_PASSWORD_STORES, _GPU_FLAG_WORDS, os and shlex at module level, so the test's AST extraction is complete, and the gate assertions at runtime-test.py:157-164 now run against the unpatched upstream file.
• Between 2026.8.31 and 2026.9.7 the desktop workspace's dependencies, the pack script, write-build-stamp.mjs and the six install.sh flags the installer passes are unchanged, so depends and the GITHUB_SHA stamping still hold.
• On quattro, the installer is the only consumer of runtime.patch; omarchy-remove-ai-hermes does not reverse it.

Found

No defect in the diff, and nothing was pushed; the branch is unchanged.

The one thing that would hurt a user is when this lands rather than what it changes. release_ring: fast publishes to edge, rc and stable on the next auto-release tick, and the installer on quattro and in both 4.0.3rc pins still does from hermes_cli.main import _write_desktop_build_stamp, which the new release no longer provides through any re-export or lazy attribute. A first "AI → Hermes" install on edge or rc would copy the app and then exit on the ImportError before the stamp is written and the app launched. omacom/omarchy#10846 fixes the import; stable's v4.0.2 has no Hermes installer, so nothing there consumes the package.

Codex at xhigh reasoning reviewed the same head and agreed with that; it had this session's files readable, so its independence on that point is not guaranteed. It contributed one thing on its own: after such a failed first run, a retry sees the app already in place at bin/omarchy-install-ai-hermes:108 and skips the copy-and-stamp branch entirely, so desktop-build-stamp.json is never written even once #10846 is installed. Verified against the source: _stamp_is_current in hermes_cli/main_web_build.py returns false for a missing file, so a later hermes desktop run from a terminal treats the packaged app as stale and rebuilds it. The packaged launcher and the in-app updater do not read that stamp, so the cost is one unnecessary rebuild, and it is only reachable through the timing window above. That gap belongs to the installer, not to this package.

Next

Waits on the maintainer: land omarchy#10846 on quattro and into an rc build, then merge. Having the installer's retry path write the stamp when the app is already present would close the recovery gap, and is worth folding into #10846. The PR body was rewritten to the house writing rules; the original text is in the edit history.

— 🤖 Fable 5.1 in Claude Code, posting on behalf of @spencerbull. Second opinion by Codex XHigh.