[GH-ISSUE #3419] [Bug] Setup offers automated Hopper installation on Linux arm64, but every pinned Hopper package is x86_64 #1275

New issue

Closed

opened 2026-10-16 21:03:39 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:03:39 +00:00

Owner

Originally created by @DavidFB-creator on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3419

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

On an Ubuntu 24.04 aarch64 host, rea setup --install-hopper plans to download and install the official Hopper Linux demo package. The .deb it pins is Architecture: amd64, so that install cannot work on this host. All three pinned Linux packages (.deb, .rpm, Arch .pkg.tar.xz) are x86_64-only.

I did not apply the plan, so I have not observed the package-manager failure itself.

Reproduction

Ran once each, on Ubuntu 24.04.5 LTS aarch64:

npx --yes rea-agents@6.4.0 setup --client claude_code --install-hopper --dry-run
The plan contains install_hopper with origin https://www.hopperapp.com:443/downloader/public/Hopper-6.4.2-Linux-demo.deb and command pkexec apt-get install -y <verified-hopper.deb> xvfb xauth python3 libx11-6 libxtst6. No architecture limitation is reported.
I downloaded the three pinned packages (with User-Agent: rea-installer, as HopperDownload.ts does) and inspected them. Size and SHA-1 match SUPPORTED_RELEASES, and each one is x86_64-only (output below).

Expected behavior

Setup should neither plan nor offer automated Hopper installation on a Linux host whose CPU architecture has no vendor package. On non-x64 Linux, --install-hopper should be refused before any download, as unsupported_host already is for unsupported distributions, and should point to an existing supported provider such as Ghidra. This expectation is mine and not yet in the docs: docs/installation.md#hopper lists the supported distributions and "64-bit Arch Linux", and the setup message says "selected 64-bit Linux distributions". Neither says that x86_64 is required.

Impact and scope

Observed: on this arm64 host the plan proposes an external download and a privileged package-manager command for a package that targets another architecture.
Unverified: what apt does when the plan is applied. I expect it to refuse the wrong-architecture package. With amd64 multiarch enabled, it might try to resolve amd64 Qt6 dependencies; I have not tested this.
Source-derived scope: any Linux arm64 host whose /etc/os-release matches the supported list (Ubuntu 24.04+, Fedora 41+, Nobara 44+, Arch, CachyOS, Omarchy) would be treated as supported. This was not tested on those other distributions.
Not observed: whether interactive setup also offers Hopper on such hosts. Per source, the same hopperInstallSupported gate applies.

REA version

6.4.0 (npx rea-agents@6.4.0); source references at 322506d0c

Runtime and platform

Node v24.18.1; Ubuntu 24.04.5 LTS, Linux 7.0, aarch64; Hopper not installed; Ghidra 12.1.4 (user-built linux_arm_64 natives)

Target and artifact context

Not applicable

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Setup dry run (excerpt):

plannedActions[2]:
  - id: install_hopper
    kind: install_hopper
    label: Hopper deep-analysis provider
    target: system package manager
    external: true
    operation: install
    networkOrigins[1]: "https://www.hopperapp.com:443/downloader/public/Hopper-6.4.2-Linux-demo.deb"
    commands[1]: pkexec apt-get install -y <verified-hopper.deb> xvfb xauth python3 libx11-6 libxtst6
    integrity: 35755772 bytes · SHA-1 e4f79dff602648a8ff4a88b773875b6bfac0dc65

Pinned packages (dpkg --print-architecture → arm64):

$ sha1sum hopper.deb hopper.rpm hopper.pkg.tar.xz
e4f79dff602648a8ff4a88b773875b6bfac0dc65  hopper.deb
b9a65f2f583a386d440d4401d9140aef3bf305de  hopper.rpm
92d780b61cab38eda95dc4112dee4fbeb0920f46  hopper.pkg.tar.xz

$ dpkg-deb -f hopper.deb Package Version Architecture
Package: hopper
Version: 6.4.2
Architecture: amd64

$ file hopper.rpm
hopper.rpm: RPM v3.0 bin i386/x86_64

$ tar -xJOf hopper.pkg.tar.xz .PKGINFO | grep -E '^(pkgver|arch) '
pkgver = 6.4.2-1
arch = x86_64

Typed outcome or recovery expected

A typed refusal before any download, e.g. the existing unsupported_host reason, with a remediation pointing to Ghidra or another available provider. Doctor/setup output should state that automated Hopper installation requires an x86_64 Linux host.

Analysis or suspected cause

Source-derived, at 322506d0c:

LinuxHopper.ts#L238-L252: hopperSetupSupported is derived only from the os-release ID / VERSION_ID, with no CPU-architecture input.
SetupPlan.ts#L59-L63 and SetupHost.ts#L132-L134 gate planning and preflight on that distribution flag alone.
LinuxHopper.ts#L26-L44 pins one package per family, and each one is x86_64-only (see above).
DoctorHost already carries the host architecture (Doctor.ts#L424), so the owning support decision could include it. This is a proposal, not tested.

Additional context

Ghidra works on this host after building its linux_arm_64 natives (support/gradle/gradlew buildNatives). Doctor reports it healthy and rea decompile --provider ghidra succeeds on an arm64 ELF, so Ghidra is a viable recovery path here.

Originally created by @DavidFB-creator on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3419 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior On an Ubuntu 24.04 **aarch64** host, `rea setup --install-hopper` plans to download and install the official Hopper Linux demo package. The `.deb` it pins is `Architecture: amd64`, so that install cannot work on this host. All three pinned Linux packages (`.deb`, `.rpm`, Arch `.pkg.tar.xz`) are x86_64-only. I did **not** apply the plan, so I have not observed the package-manager failure itself. ### Reproduction Ran once each, on Ubuntu 24.04.5 LTS aarch64: 1. `npx --yes rea-agents@6.4.0 setup --client claude_code --install-hopper --dry-run` 2. The plan contains `install_hopper` with origin `https://www.hopperapp.com:443/downloader/public/Hopper-6.4.2-Linux-demo.deb` and command `pkexec apt-get install -y <verified-hopper.deb> xvfb xauth python3 libx11-6 libxtst6`. No architecture limitation is reported. 3. I downloaded the three pinned packages (with `User-Agent: rea-installer`, as `HopperDownload.ts` does) and inspected them. Size and SHA-1 match `SUPPORTED_RELEASES`, and each one is x86_64-only (output below). ### Expected behavior Setup should neither plan nor offer automated Hopper installation on a Linux host whose CPU architecture has no vendor package. On non-x64 Linux, `--install-hopper` should be refused before any download, as `unsupported_host` already is for unsupported distributions, and should point to an existing supported provider such as Ghidra. This expectation is mine and not yet in the docs: `docs/installation.md#hopper` lists the supported distributions and "64-bit Arch Linux", and the setup message says "selected 64-bit Linux distributions". Neither says that x86_64 is required. ### Impact and scope - Observed: on this arm64 host the plan proposes an external download and a privileged package-manager command for a package that targets another architecture. - Unverified: what apt does when the plan is applied. I expect it to refuse the wrong-architecture package. With `amd64` multiarch enabled, it might try to resolve amd64 Qt6 dependencies; I have not tested this. - Source-derived scope: any Linux arm64 host whose `/etc/os-release` matches the supported list (Ubuntu 24.04+, Fedora 41+, Nobara 44+, Arch, CachyOS, Omarchy) would be treated as supported. This was not tested on those other distributions. - Not observed: whether interactive setup also offers Hopper on such hosts. Per source, the same `hopperInstallSupported` gate applies. ### REA version 6.4.0 (`npx rea-agents@6.4.0`); source references at `322506d0c` ### Runtime and platform Node v24.18.1; Ubuntu 24.04.5 LTS, Linux 7.0, aarch64; Hopper not installed; Ghidra 12.1.4 (user-built `linux_arm_64` natives) ### Target and artifact context Not applicable ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Setup dry run (excerpt): ``` plannedActions[2]: - id: install_hopper kind: install_hopper label: Hopper deep-analysis provider target: system package manager external: true operation: install networkOrigins[1]: "https://www.hopperapp.com:443/downloader/public/Hopper-6.4.2-Linux-demo.deb" commands[1]: pkexec apt-get install -y <verified-hopper.deb> xvfb xauth python3 libx11-6 libxtst6 integrity: 35755772 bytes · SHA-1 e4f79dff602648a8ff4a88b773875b6bfac0dc65 ``` Pinned packages (`dpkg --print-architecture` → `arm64`): ``` $ sha1sum hopper.deb hopper.rpm hopper.pkg.tar.xz e4f79dff602648a8ff4a88b773875b6bfac0dc65 hopper.deb b9a65f2f583a386d440d4401d9140aef3bf305de hopper.rpm 92d780b61cab38eda95dc4112dee4fbeb0920f46 hopper.pkg.tar.xz $ dpkg-deb -f hopper.deb Package Version Architecture Package: hopper Version: 6.4.2 Architecture: amd64 $ file hopper.rpm hopper.rpm: RPM v3.0 bin i386/x86_64 $ tar -xJOf hopper.pkg.tar.xz .PKGINFO | grep -E '^(pkgver|arch) ' pkgver = 6.4.2-1 arch = x86_64 ``` ### Typed outcome or recovery expected A typed refusal before any download, e.g. the existing `unsupported_host` reason, with a remediation pointing to Ghidra or another available provider. Doctor/setup output should state that automated Hopper installation requires an x86_64 Linux host. ### Analysis or suspected cause Source-derived, at `322506d0c`: - [`LinuxHopper.ts#L238-L252`](https://github.com/morluto/rea/blob/322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7/src/application/LinuxHopper.ts#L238-L252): `hopperSetupSupported` is derived only from the os-release `ID` / `VERSION_ID`, with no CPU-architecture input. - [`SetupPlan.ts#L59-L63`](https://github.com/morluto/rea/blob/322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7/src/application/SetupPlan.ts#L59-L63) and [`SetupHost.ts#L132-L134`](https://github.com/morluto/rea/blob/322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7/src/application/SetupHost.ts#L132-L134) gate planning and preflight on that distribution flag alone. - [`LinuxHopper.ts#L26-L44`](https://github.com/morluto/rea/blob/322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7/src/application/LinuxHopper.ts#L26-L44) pins one package per family, and each one is x86_64-only (see above). - `DoctorHost` already carries the host architecture ([`Doctor.ts#L424`](https://github.com/morluto/rea/blob/322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7/src/application/Doctor.ts#L424)), so the owning support decision could include it. This is a proposal, not tested. ### Additional context Ghidra works on this host after building its `linux_arm_64` natives (`support/gradle/gradlew buildNatives`). Doctor reports it healthy and `rea decompile --provider ghidra` succeeds on an arm64 ELF, so Ghidra is a viable recovery path here.

bsakaguchi referenced this issue

2026-10-17 21:09:54 +00:00

[PR #1275] [MERGED] fix(hopper): allow restart after verified owned-provider shutdown #2758

bsakaguchi referenced this issue

2026-10-31 00:29:51 +00:00

[GH-ISSUE #2975] [Bug] macOS: after the Hopper app exits, the MCP session cannot open any target until the server restarts #1046

bsakaguchi closed this issue

2026-10-31 00:30:23 +00:00