morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #2270] [Bug] Hopper not detected on Linux during setup #751

New issue

Closed

opened 2026-10-15 18:27:58 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 18:27:58 +00:00

Owner

Originally created by @ppabis on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2270

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

rea setup command still tries to install Hopper regardless of which version is present (6.5.0 or 6.4.2).

It doesn't perform any verification, even with HOPPER_LAUNCHER_PATH set.

It would be highly advisable to allow to skip its installation or elevate sudo access during process runtime.

Reproduction

Run rea setup as normal user on Linux.

Expected behavior

It should detect Hopper being already present.

Impact and scope

Very difficult to set up.

REA version

6.4.0

Runtime and platform

Ubuntu 26.04.1 LTS

Target and artifact context

not applicable

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Typed outcome or recovery expected

No response

Analysis or suspected cause

No response

Additional context

No response

Originally created by @ppabis on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2270 ### 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 `rea setup` command still tries to install Hopper regardless of which version is present (6.5.0 or 6.4.2). It doesn't perform any verification, even with `HOPPER_LAUNCHER_PATH` set. It would be highly advisable to allow to skip its installation or elevate sudo access during process runtime. ### Reproduction 1. Run `rea setup` as normal user on Linux. ### Expected behavior It should detect Hopper being already present. ### Impact and scope Very difficult to set up. ### REA version 6.4.0 ### Runtime and platform Ubuntu 26.04.1 LTS ### Target and artifact context not applicable ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence ```text ``` ### Typed outcome or recovery expected _No response_ ### Analysis or suspected cause _No response_ ### Additional context _No response_

bsakaguchi

2026-10-15 18:27:58 +00:00

closed this issue
added the
bug

P2: medium
labels

bsakaguchi commented

2026-10-15 18:28:00 +00:00

Author

Owner

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026):

Triage note: I couldn't reproduce this because it needs Linux with Hopper installed (I'm on macOS), so I'm skipping a fix. Source pointer, current main ec2d251c0:

In discoverSetupState (src/application/SetupPlan.ts), setup proposes install_hopper when the install is supported and proposed, and either:

no provider environment was discovered, or
linuxHopperRepairNeeded is true. That is true if the initial doctor run reports a failing hopper-demo-runtime check, or a failing hopper-version check whose detail is /opt/hopper/bin/Hopper.

So with an existing install (including when HOPPER_LAUNCHER_PATH is set), the repeated install proposal most likely comes from one of those two doctor checks failing on this host. That could be a 6.5.0 or licensed (non-demo) build not matching what the check expects, or the version probe failing at /opt/hopper/bin/Hopper.

Could you attach the output of rea doctor --json from the same shell? The hopper-version and hopper-demo-runtime entries (ok, detail, remediation) and hopperPath would show which branch is taken, with paths redacted as needed. Also mention whether Hopper was installed from the .deb or another way, and where its launcher lives.

As a workaround for the prompt itself, rea setup --client <name> --yes without --install-hopper should not install Hopper non-interactively, since the install also needs approval.

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026): Triage note: I couldn't reproduce this because it needs Linux with Hopper installed (I'm on macOS), so I'm skipping a fix. Source pointer, current main ec2d251c0: In `discoverSetupState` (`src/application/SetupPlan.ts`), setup proposes `install_hopper` when the install is supported and proposed, and either: - no provider environment was discovered, or - `linuxHopperRepairNeeded` is true. That is true if the initial doctor run reports a failing `hopper-demo-runtime` check, or a failing `hopper-version` check whose detail is `/opt/hopper/bin/Hopper`. So with an existing install (including when `HOPPER_LAUNCHER_PATH` is set), the repeated install proposal most likely comes from one of those two doctor checks failing on this host. That could be a 6.5.0 or licensed (non-demo) build not matching what the check expects, or the version probe failing at `/opt/hopper/bin/Hopper`. Could you attach the output of `rea doctor --json` from the same shell? The `hopper-version` and `hopper-demo-runtime` entries (`ok`, `detail`, `remediation`) and `hopperPath` would show which branch is taken, with paths redacted as needed. Also mention whether Hopper was installed from the `.deb` or another way, and where its launcher lives. As a workaround for the prompt itself, `rea setup --client <name> --yes` without `--install-hopper` should not install Hopper non-interactively, since the install also needs approval.

bsakaguchi commented

2026-10-15 18:28:00 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Triage & Setup Idempotency Notes

Per AGENTS.md ("rea setup must show its planned changes and require approval before writing files or installing Hopper"):

Idempotency & Environment Overrides: If HOPPER_LAUNCHER_PATH is set and points to a functioning executable, rea setup and rea doctor must probe its version and treat Hopper as satisfied rather than prompting for installation.
Elevated Privileges: REA deliberately avoids ambient sudo escalation during setup. Bypassing installation when Hopper is already discovered via environment variable or standard binary path (/opt/hopper-v4/bin/hopper / /usr/bin/hopper) prevents unnecessary install prompts on Linux.

@matbrgz commented on GitHub (Oct 12, 2026): ### Triage & Setup Idempotency Notes Per `AGENTS.md` ("`rea setup` must show its planned changes and require approval before writing files or installing Hopper"): 1. **Idempotency & Environment Overrides:** If `HOPPER_LAUNCHER_PATH` is set and points to a functioning executable, `rea setup` and `rea doctor` must probe its version and treat Hopper as satisfied rather than prompting for installation. 2. **Elevated Privileges:** REA deliberately avoids ambient `sudo` escalation during setup. Bypassing installation when Hopper is already discovered via environment variable or standard binary path (`/opt/hopper-v4/bin/hopper` / `/usr/bin/hopper`) prevents unnecessary install prompts on Linux.

bsakaguchi commented

2026-10-15 18:28:00 +00:00

Author

Owner

@hussnainahmedd commented on GitHub (Oct 13, 2026):

I'd like to work on this.

@hussnainahmedd commented on GitHub (Oct 13, 2026): I'd like to work on this.

bsakaguchi commented

2026-10-15 18:28:00 +00:00

Author

Owner

@ppabis commented on GitHub (Oct 13, 2026):

Somehow new terminal session fixed it? The variable definitely was exported before I ran rea setup --client hermes but now it simply reports Detected provider environment: HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper. Existing server environment overrides are retained; detected values replace matching keys.

Closing this issue then.

@ppabis commented on GitHub (Oct 13, 2026): Somehow new terminal session fixed it? The variable definitely was exported before I ran `rea setup --client hermes` but now it simply reports `Detected provider environment: HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper. Existing server environment overrides are retained; detected values replace matching keys.` Closing this issue then.

bsakaguchi referenced this issue

2026-10-16 21:15:45 +00:00

[PR #751] [MERGED] fix(firmware): validate configured executables #2213

bsakaguchi referenced this issue

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

[PR #1661] [CLOSED] fix: reject directory paths for the Wakaru limiter and mitmdump #4733