fix(desktop): configure Linux Electron sandbox helper

[Jgracier]

Why

hermes desktop builds an unpacked Electron app on Linux, but Electron's generated chrome-sandbox helper is user-owned with mode 755. Chromium aborts before the desktop app starts unless that helper is owned by root with mode 4755.

The existing install.sh --include-desktop path was also macOS-only after the build step: it searched only for Hermes.app, so a successful Linux build was reported as missing.

What changed

• Configure the Linux Electron sandbox helper as root:root 4755 before launching a locally built desktop app.
• Recognize the Linux unpacked desktop artifact in install.sh --include-desktop and configure its sandbox helper after build.
• Add regression coverage for the Linux launcher repair path.

Verification

• bash -n scripts/install.sh
• python -m pytest tests/hermes_cli/test_gui_command.py -q
• python -m pytest tests/test_install_sh_setup_wizard_tty_probe.py tests/test_install_sh_root_fhs_uv_python_path.py tests/test_install_sh_symlink_stomp.py -q
• Simulated a post-build user-owned 755 helper and confirmed hermes desktop --skip-build repairs it and launches the sandboxed Electron process.

[Copilot]

Pull request overview

This PR fixes Linux-specific issues when launching a locally built Electron desktop app by ensuring Electron’s chrome-sandbox helper is configured with the required root:root ownership and 4755 mode, and by updating the installer to recognize Linux unpacked desktop artifacts.

Changes:

• Add a Linux sandbox helper repair step to hermes desktop/gui before launching the packaged app.
• Update scripts/install.sh --include-desktop to detect Linux unpacked artifacts (not only macOS .app) and configure chrome-sandbox.
• Add a regression test covering the Linux launcher sandbox repair path.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
tests/hermes_cli/test_gui_command.py	Adds regression coverage asserting sudo chown/sudo chmod are invoked before launching on Linux.
scripts/install.sh	Detects Linux unpacked desktop output and attempts to configure chrome-sandbox after build.
hermes_cli/main.py	Implements Linux chrome-sandbox fixup in the packaged-app launch path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[teknium1]

Flagging a design concern on the launch-path fixup before this lands (Ari is picking this up).

The core issue: the launcher must not depend on sudo being obtainable.

_desktop_linux_sandbox_fixup() spawns sudo chown/chmod during a plain hermes desktop launch. That fails hard for a large class of users:

• locked-down / managed machines where the user has no sudo
• non-admin accounts
• containers / CI without sudo

We can't assume root is reachable, so auto-sudo can't be the default launch behavior.

The clean alternative (zero-root) is not reliably available either.

Modern Electron sandboxes via unprivileged user namespaces with no SUID helper at all — but you can't detect availability from sysctls; the knobs lie. Probed on a stock Ubuntu 24.04 box:

kernel.unprivileged_userns_clone = 1          # says "allowed"
user.max_user_namespaces = 255646             # plenty
kernel.apparmor_restrict_unprivileged_userns = 1   # but AppArmor restricts
# actual runtime test:
unshare --user --map-root-user echo ok
  -> write failed /proc/self/uid_map: Operation not permitted   # BLOCKED

So userns is blocked out of the box on current Ubuntu defaults, and the only way to know is a runtime unshare probe, not reading sysctls.

Suggested launch logic (never spawns sudo itself):

1. Runtime-probe whether an unprivileged userns can be created (try unshare, not sysctl).
2. userns works -> launch normally, full sandbox, no root. Done.
3. userns blocked but chrome-sandbox is already root:root 4755 -> launch, full sandbox.
4. userns blocked AND helper not setuid -> we cannot get a sandbox without root. Do NOT silently --no-sandbox. Print the exact chown/chmod commands for users who do have sudo, and let them opt into --no-sandbox with a clear "reduced isolation" warning.

Principle: the launcher detects and informs; it never assumes root is obtainable and never escalates on the user's behalf.

The install.sh --include-desktop changes are fine to keep — the installer path may legitimately have root and the escalation there is explicit. It's specifically the auto-sudo in the launch path that should become the probe-and-inform flow above.

Context: reported on Discord — Linux users currently have to run the manual chown/chmod dance, which is what motivated this PR. The fix is right to pursue; it just shouldn't require sudo at launch.