morluto/rea

Fork 0

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

[GH-ISSUE #3944] [Bug] Windows setup recovery recommends an unsupported Hopper installation #1551

New issue

Closed

opened 2026-10-16 21:07:02 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-16 21:07:02 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3944

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

Observed at the production application boundary with simulated Windows diagnostics, the first call returned status: "needs_human", doctor.healthy: false, no Hopper path, and empty planned and applied action lists. Its remediation began with:

Hopper is optional for non-Hopper providers. Rerun with --yes --install-hopper for deep native analysis.

The correct Grok Bot manual instructions followed that prefix. The second call, with Hopper installation requested, returned status: "needs_human", an empty applied-action list, and:

REA supports Hopper on macOS and selected 64-bit Linux distributions.

The executed checks establish the contradiction in the production workflow with a simulated platform. Source inspection establishes that the supported CLI maps the listed flags to the same options. No native Windows process output or Windows exit status was observed.

Reproduction

Use the baseline checkout listed under Runtime or environment, its installed dependencies and built runtime, and supported Node on Windows x64. No Hopper launcher should be configured or detected. Grok Bot need not be installed because explicit client selection is supported and its connector registration is manual. Use a fresh PowerShell session and an isolated configuration home. The following native Windows commands are proposed reproduction steps; they were not executed on a Windows host.

$probeHome = Join-Path ([System.IO.Path]::GetTempPath()) ([System.Guid]::NewGuid().ToString())
New-Item -ItemType Directory -Path $probeHome | Out-Null
$env:HOME = $probeHome
$env:USERPROFILE = $probeHome
$env:APPDATA = Join-Path $probeHome "AppData\Roaming"
$env:LOCALAPPDATA = Join-Path $probeHome "AppData\Local"
node scripts/rea.mjs setup --yes --client grok_bot --skill=false --json
node scripts/rea.mjs setup --yes --client grok_bot --skill=false --install-hopper --json

The first result should expose the contradictory Hopper installation advice alongside the correct Grok Bot manual connector instructions. The second command follows that advice and returns the unsupported-host message. Disabling the skill keeps this case free of local setup mutations.

The executed local reproduction used the repository's recording doctor fixture at the production diagnostics boundary, reporting Windows x64, supported Node, no Hopper executable, no providers, and no client registrations. It ran the real setup host, setup workflow and doctor with the options corresponding to these commands. Both checks passed their assertions about the faulty behavior. A third control ran the real doctor for an aligned Codex registration with client-only scope and no providers; it returned healthy, confirming that provider absence alone is insufficient to trigger this defect.

Expected behavior

Setup documents Windows agent and bundled skill configuration but explicitly excludes Hopper installation on Windows. The final recovery instructions should therefore contain only supported actions for this Windows case. Grok Bot's documented manual connector instructions are an applicable recovery. The result should not invite an installation that the same command rejects on that host.

Impact and scope

The verified defect is misleading recovery wording. Following the recommendation rejects the unsupported host before mutations, and the original result still includes the correct Grok Bot manual connector instructions. Those existing manual instructions provide an available workaround. No analysis result or user configuration changed in the executed boundary reproduction. Native Windows CLI output and exit status remain untested.

REA version

rea 6.5.0 at source commit 4692bb3330; freshness checked by source at origin/main 22ec8bdb2f

Runtime and platform

Node 24.18.0; macOS arm64. The production diagnostics fixture simulated Windows x64 with no Hopper executable, providers or registrations; no native Windows host or real provider ran.

Target and artifact context

not applicable

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Three focused checks ran through real runSetup, systemSetupHost and runDoctor with the repository's createDoctorHostFixture simulating Windows diagnostics. The first returned needs_human, an unhealthy doctor, no Hopper path, no planned/applied actions, and the unsupported --install-hopper prefix. Requesting installation returned the platform rejection before mutations. The aligned-Codex/client-only control returned healthy without providers, confirming that missing optional providers alone does not trigger the defect.

Reachability is source-derived from src/cli/setupCommands.ts:214-283, src/application/SetupPlan.ts:59-69, src/application/SupportedClients.ts:699-704, and src/application/DoctorScope.ts:142-153. Grok Bot is an explicit supported manual registration and requires no local write with the skill disabled.

Failure source: src/application/Setup.ts:356-375,519-531. This code is unchanged on current main. The cited-file changes since baseline concern Linux publisher/cache verification; the Windows rejection in src/application/SetupHost.ts:120-130 and the unsupported-advice branch remain intact by source inspection. Expected platform contract: docs/installation.md:795-800; Grok Bot manual recovery: docs/client-configuration.md:421-436.

Missing evidence: actual output from the two proposed commands on a native Windows x64 host without a detected Hopper launcher.

Typed outcome or recovery expected

Repeat the Windows case and require the final remediation to omit --install-hopper while retaining the applicable manual registration guidance and the truthful needs_human status. The passing result must not hide the unhealthy client check or pretend to configure the hosted connector. Keep rejecting explicit Hopper installation on Windows before mutations. As controls, an aligned local client with no requested provider should remain healthy, and an unhealthy Hopper-less setup on a supported macOS or Linux installer host should retain its supported installation advice.

Analysis or suspected cause

Source-derived: finalSetupRemediation adds Hopper installation advice whenever final readiness is unhealthy and no Hopper path exists, without excluding Windows. The installation guard correctly rejects Windows.

Additional context

This requests correction of Windows recovery advice, not Windows Hopper support. No hosted connector was configured. The proposed native Windows commands are explicitly unexecuted; the production application boundary was exercised with simulated platform diagnostics.

Originally created by @coygeek on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3944 ### 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 Observed at the production application boundary with simulated Windows diagnostics, the first call returned `status: "needs_human"`, `doctor.healthy: false`, no Hopper path, and empty planned and applied action lists. Its remediation began with: ```text Hopper is optional for non-Hopper providers. Rerun with --yes --install-hopper for deep native analysis. ``` The correct Grok Bot manual instructions followed that prefix. The second call, with Hopper installation requested, returned `status: "needs_human"`, an empty applied-action list, and: ```text REA supports Hopper on macOS and selected 64-bit Linux distributions. ``` The executed checks establish the contradiction in the production workflow with a simulated platform. Source inspection establishes that the supported CLI maps the listed flags to the same options. No native Windows process output or Windows exit status was observed. ### Reproduction Use the baseline checkout listed under Runtime or environment, its installed dependencies and built runtime, and supported Node on Windows x64. No Hopper launcher should be configured or detected. Grok Bot need not be installed because explicit client selection is supported and its connector registration is manual. Use a fresh PowerShell session and an isolated configuration home. The following native Windows commands are proposed reproduction steps; they were not executed on a Windows host. ```powershell $probeHome = Join-Path ([System.IO.Path]::GetTempPath()) ([System.Guid]::NewGuid().ToString()) New-Item -ItemType Directory -Path $probeHome | Out-Null $env:HOME = $probeHome $env:USERPROFILE = $probeHome $env:APPDATA = Join-Path $probeHome "AppData\Roaming" $env:LOCALAPPDATA = Join-Path $probeHome "AppData\Local" node scripts/rea.mjs setup --yes --client grok_bot --skill=false --json node scripts/rea.mjs setup --yes --client grok_bot --skill=false --install-hopper --json ``` The first result should expose the contradictory Hopper installation advice alongside the correct Grok Bot manual connector instructions. The second command follows that advice and returns the unsupported-host message. Disabling the skill keeps this case free of local setup mutations. The executed local reproduction used the repository's recording doctor fixture at the production diagnostics boundary, reporting Windows x64, supported Node, no Hopper executable, no providers, and no client registrations. It ran the real setup host, setup workflow and doctor with the options corresponding to these commands. Both checks passed their assertions about the faulty behavior. A third control ran the real doctor for an aligned Codex registration with client-only scope and no providers; it returned healthy, confirming that provider absence alone is insufficient to trigger this defect. ### Expected behavior Setup documents Windows agent and bundled skill configuration but explicitly excludes Hopper installation on Windows. The final recovery instructions should therefore contain only supported actions for this Windows case. Grok Bot's documented manual connector instructions are an applicable recovery. The result should not invite an installation that the same command rejects on that host. ### Impact and scope The verified defect is misleading recovery wording. Following the recommendation rejects the unsupported host before mutations, and the original result still includes the correct Grok Bot manual connector instructions. Those existing manual instructions provide an available workaround. No analysis result or user configuration changed in the executed boundary reproduction. Native Windows CLI output and exit status remain untested. ### REA version rea 6.5.0 at source commit 4692bb33300c7cb77b095b6cc0c33da861c1b860; freshness checked by source at origin/main 22ec8bdb2f7d4626587f23b1eed4a207df600386 ### Runtime and platform Node 24.18.0; macOS arm64. The production diagnostics fixture simulated Windows x64 with no Hopper executable, providers or registrations; no native Windows host or real provider ran. ### Target and artifact context not applicable ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Three focused checks ran through real `runSetup`, `systemSetupHost` and `runDoctor` with the repository's `createDoctorHostFixture` simulating Windows diagnostics. The first returned `needs_human`, an unhealthy doctor, no Hopper path, no planned/applied actions, and the unsupported `--install-hopper` prefix. Requesting installation returned the platform rejection before mutations. The aligned-Codex/client-only control returned healthy without providers, confirming that missing optional providers alone does not trigger the defect. Reachability is source-derived from `src/cli/setupCommands.ts:214-283`, `src/application/SetupPlan.ts:59-69`, `src/application/SupportedClients.ts:699-704`, and `src/application/DoctorScope.ts:142-153`. Grok Bot is an explicit supported manual registration and requires no local write with the skill disabled. Failure source: `src/application/Setup.ts:356-375,519-531`. This code is unchanged on current main. The cited-file changes since baseline concern Linux publisher/cache verification; the Windows rejection in `src/application/SetupHost.ts:120-130` and the unsupported-advice branch remain intact by source inspection. Expected platform contract: `docs/installation.md:795-800`; Grok Bot manual recovery: `docs/client-configuration.md:421-436`. Missing evidence: actual output from the two proposed commands on a native Windows x64 host without a detected Hopper launcher. ### Typed outcome or recovery expected Repeat the Windows case and require the final remediation to omit `--install-hopper` while retaining the applicable manual registration guidance and the truthful `needs_human` status. The passing result must not hide the unhealthy client check or pretend to configure the hosted connector. Keep rejecting explicit Hopper installation on Windows before mutations. As controls, an aligned local client with no requested provider should remain healthy, and an unhealthy Hopper-less setup on a supported macOS or Linux installer host should retain its supported installation advice. ### Analysis or suspected cause Source-derived: `finalSetupRemediation` adds Hopper installation advice whenever final readiness is unhealthy and no Hopper path exists, without excluding Windows. The installation guard correctly rejects Windows. ### Additional context This requests correction of Windows recovery advice, not Windows Hopper support. No hosted connector was configured. The proposed native Windows commands are explicitly unexecuted; the production application boundary was exercised with simulated platform diagnostics.

bsakaguchi commented

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

Author

Owner

@XinwangTao commented on GitHub (Oct 15, 2026):

Confirmed UX contradiction: the recovery hint tells a Windows user to rerun with --install-hopper, yet the platform gate then rejects Windows outright. The remediation message should be platform-aware from the start — either omit the Hopper suggestion on unsupported hosts or phrase it as "not available on Windows" rather than an actionable flag.

@XinwangTao commented on GitHub (Oct 15, 2026): Confirmed UX contradiction: the recovery hint tells a Windows user to rerun with --install-hopper, yet the platform gate then rejects Windows outright. The remediation message should be platform-aware from the start — either omit the Hopper suggestion on unsupported hosts or phrase it as "not available on Windows" rather than an actionable flag.

bsakaguchi commented

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

Author

Owner

@biniyapp commented on GitHub (Oct 15, 2026):

I am working on a focused fix for the unsupported Hopper installation hint, with regression coverage for Windows manual-client recovery and supported-host controls. I will open a draft PR and distinguish simulated-platform coverage from native Windows verification.

@biniyapp commented on GitHub (Oct 15, 2026): I am working on a focused fix for the unsupported Hopper installation hint, with regression coverage for Windows manual-client recovery and supported-host controls. I will open a draft PR and distinguish simulated-platform coverage from native Windows verification.

bsakaguchi commented

2026-10-16 21:07:04 +00:00

Author

Owner

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

Cross-referencing with #3419 ([Bug] Setup offers automated Hopper installation on Linux arm64, but every pinned Hopper package is x86_64). Both pinpoint rea setup advising or attempting automated Hopper installation on unsupported platforms (Windows and Linux arm64).

Consolidated under Cluster Q (Unsupported Platform Hopper Installation Remediation) in tracker #4330.

@matbrgz commented on GitHub (Oct 16, 2026): Cross-referencing with #3419 (`[Bug] Setup offers automated Hopper installation on Linux arm64, but every pinned Hopper package is x86_64`). Both pinpoint `rea setup` advising or attempting automated Hopper installation on unsupported platforms (Windows and Linux arm64). Consolidated under **Cluster Q (Unsupported Platform Hopper Installation Remediation)** in tracker #4330.

bsakaguchi referenced this issue

2026-10-17 21:01:59 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

bsakaguchi referenced this issue

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

[GH-ISSUE #1551] Feature: Add support for Binary Ninja as an analysis backend #524

bsakaguchi closed this issue

2026-10-31 00:31:25 +00:00

bsakaguchi referenced this issue

2026-10-31 00:48:24 +00:00

[GH-ISSUE #7095] [Feature] Add integration for the Binary Ninja tool #4273

bsakaguchi referenced this issue