morluto/rea

Fork 0

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

[GH-ISSUE #3501] [Bug] Installing from source omits the Windows native artifact, so every provider is rejected as unsupported_host #1305

New issue

Closed

opened 2026-10-16 21:03:59 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

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

Owner

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

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

Installing REA from source on Windows leaves native/windows/build/ empty, because
that directory is gitignored. The result is that every provider-backed operation
is rejected, while rea doctor still reports the Ghidra provider as fully healthy.
Observed sequence on Windows 11 23H2 with a fully conforming Ghidra + JDK 21 setup:

rea doctor reports the Ghidra provider healthy — all eight checks pass
(installation, platform, architecture, version, headless script, native
decompiler, and JDK 21 acceptance).
rea analyze then fails with provider_unavailable, rejecting
ghidra as unsupported_host, because the manifest is absent.
The rejection reason names a missing file but gives no recovery action:
1.REA Windows native controls are unavailable:
2.ENOENT: no such file or directory,
3.open '...\rea\native\windows\build\manifest.json'

Reproduction

git clone https://github.com/morluto/rea.git
npm install --ignore-scripts # postinstall hits EBUSY on vitepress/esbuild
npm run compile
set GHIDRA_INSTALL_DIR=E:\tools\ghidra_12.1.4_PUBLIC
set JAVA_HOME=E:\tools\jdk-21.0.12.1+1
rea doctor # ghidra: ok (8/8 checks)
rea analyze C:\Windows\System32\notepad.exe -> provider_unavailable / unsupported_host (see evidence below)
Reproduced 100% of attempts; deterministic, not intermittent.

Expected behavior

Either of these, in order of preference:

rea setup (or the documented install flow) makes the source tree runnable on
Windows — e.g. by fetching the prebuilt artifact for the host platform when
native/windows/build/ is absent — so a Windows user does not need a Linux
cross-compilation toolchain to use a feature that is already built and published.
At minimum, the rejection message and rea doctor name the exact missing artifact
and the one command that fixes it, instead of only reporting the ENOENT path.
Note that native/windows/README.md currently documents the build lane as requiring
Linux + MinGW-w64, which is accurate for building but gives a source-installing
Windows user no path to an artifact that already ships in the npm tarball.

Impact and scope

Observed: on Windows, a source install cannot run any provider-backed operation
until the artifact is placed manually — the Ghidra lane and, by the same
self-check gate, the other native lanes. Untested scope: I only exercised the Ghidra
provider. Severity for a source-installing Windows user is total (no native analysis
possible), but recovery is trivial once the artifact is supplied, so this reads as a
packaging/documentation gap rather than an engine defect.

REA version

6.4.0, source revision 80592b82a

Runtime and platform

Node 22.22.2; Win11 23H2 build 22631.4602; JDK 21.0.12.1; Ghidra 12.1.4

Target and artifact context

PE x86_64 executable (C:\Windows\System32\notepad.exe)

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

(a) The rejection — all eight Ghidra checks pass, yet ghidra is rejected as
unsupported_host because the native manifest is absent:
{
"code": "provider_unavailable",
"details": {
"rejections": [{
"provider_id": "ghidra",
"code": "unsupported_host",
"reason": "REA Windows native controls are unavailable: ENOENT: no such
file or directory, open '...\native\windows\build\manifest.json'",
"diagnostics": {
"install_dir": "E:\tools\ghidra_12.1.4_PUBLIC",
"provider_version": "12.1.4",
"java_version": "21.0.12.1",
"platform": "win32",
"architecture": "x64",
"checks": [
{"name":"configuration","ok":true},
{"name":"platform","ok":true},
{"name":"architecture","ok":true},
{"name":"installation","ok":true},
{"name":"version","ok":true},
{"name":"headless","ok":true},
{"name":"native_decompiler","ok":true},
{"name":"java","ok":true}
]
}
}]
}
}
(b) Recovery is trivial, and proves the controls work on this host — copying the
published artifact into the source tree makes the same command succeed end to end:
npm pack rea-agents@6.4.0
tar -xzf rea-agents-6.4.0.tgz
cp package/native/windows/build/rea-windows-x64.node /native/windows/build/
cp package/native/windows/build/manifest.json /native/windows/build/
And rea analyze C:\Windows\System32\notepad.exe --json completes: format pe,
architecture x86_64, image base 0x140000000, 9 segments, 915 procedures,
635 strings.
(c) How this differs from existing reports — so it is not read as a duplicate:

#527 (REA 3.2.1, closed): the authority gate was unconditional in committed code at
that time. In 6.4.0 the gate is satisfied once the artifact is present, and (b)
above shows a real successful run on Windows.
#3111 / #1701 / #2196 (open): those hosts have rea-windows-x64.node present and
loading, and fail at the runtime self-test with Delete owned object by handle
failed (Win32 5). Mine is a different failure — the artifact is absent entirely,
reported as ENOENT, and no runtime self-test is ever reached.
If useful to those threads: my host (Windows 11 23H2, build 22631.4602,
non-elevated, Defender only, %TEMP% on local NTFS C:) passes the native
authority self-test and completes Ghidra analysis, which may help narrow the
host-dependent factor under review in #2445.

Typed outcome or recovery expected

No response

Analysis or suspected cause

No response

Additional context

No response

Originally created by @e-micsun on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3501 ### 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 Installing REA from source on Windows leaves native/windows/build/ empty, because that directory is gitignored. The result is that every provider-backed operation is rejected, while rea doctor still reports the Ghidra provider as fully healthy. Observed sequence on Windows 11 23H2 with a fully conforming Ghidra + JDK 21 setup: 1. rea doctor reports the Ghidra provider healthy — all eight checks pass (installation, platform, architecture, version, headless script, native decompiler, and JDK 21 acceptance). 2. rea analyze <pe binary> then fails with provider_unavailable, rejecting ghidra as unsupported_host, because the manifest is absent. The rejection reason names a missing file but gives no recovery action: 1.REA Windows native controls are unavailable: 2.ENOENT: no such file or directory, 3.open '...\rea\native\windows\build\manifest.json' ### Reproduction 1. git clone https://github.com/morluto/rea.git 2. npm install --ignore-scripts # postinstall hits EBUSY on vitepress/esbuild 3. npm run compile 4. set GHIDRA_INSTALL_DIR=E:\tools\ghidra_12.1.4_PUBLIC 5. set JAVA_HOME=E:\tools\jdk-21.0.12.1+1 6. rea doctor # ghidra: ok (8/8 checks) 7. rea analyze C:\Windows\System32\notepad.exe -> provider_unavailable / unsupported_host (see evidence below) Reproduced 100% of attempts; deterministic, not intermittent. ### Expected behavior Either of these, in order of preference: 1. rea setup (or the documented install flow) makes the source tree runnable on Windows — e.g. by fetching the prebuilt artifact for the host platform when native/windows/build/ is absent — so a Windows user does not need a Linux cross-compilation toolchain to use a feature that is already built and published. 2. At minimum, the rejection message and rea doctor name the exact missing artifact and the one command that fixes it, instead of only reporting the ENOENT path. Note that native/windows/README.md currently documents the build lane as requiring Linux + MinGW-w64, which is accurate for building but gives a source-installing Windows user no path to an artifact that already ships in the npm tarball. ### Impact and scope Observed: on Windows, a source install cannot run any provider-backed operation until the artifact is placed manually — the Ghidra lane and, by the same self-check gate, the other native lanes. Untested scope: I only exercised the Ghidra provider. Severity for a source-installing Windows user is total (no native analysis possible), but recovery is trivial once the artifact is supplied, so this reads as a packaging/documentation gap rather than an engine defect. ### REA version 6.4.0, source revision 80592b82a ### Runtime and platform Node 22.22.2; Win11 23H2 build 22631.4602; JDK 21.0.12.1; Ghidra 12.1.4 ### Target and artifact context PE x86_64 executable (C:\Windows\System32\notepad.exe) ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence (a) The rejection — all eight Ghidra checks pass, yet ghidra is rejected as unsupported_host because the native manifest is absent: { "code": "provider_unavailable", "details": { "rejections": [{ "provider_id": "ghidra", "code": "unsupported_host", "reason": "REA Windows native controls are unavailable: ENOENT: no such file or directory, open '...\\native\\windows\\build\\manifest.json'", "diagnostics": { "install_dir": "E:\\tools\\ghidra_12.1.4_PUBLIC", "provider_version": "12.1.4", "java_version": "21.0.12.1", "platform": "win32", "architecture": "x64", "checks": [ {"name":"configuration","ok":true}, {"name":"platform","ok":true}, {"name":"architecture","ok":true}, {"name":"installation","ok":true}, {"name":"version","ok":true}, {"name":"headless","ok":true}, {"name":"native_decompiler","ok":true}, {"name":"java","ok":true} ] } }] } } (b) Recovery is trivial, and proves the controls work on this host — copying the published artifact into the source tree makes the same command succeed end to end: npm pack rea-agents@6.4.0 tar -xzf rea-agents-6.4.0.tgz cp package/native/windows/build/rea-windows-x64.node <repo>/native/windows/build/ cp package/native/windows/build/manifest.json <repo>/native/windows/build/ And rea analyze C:\Windows\System32\notepad.exe --json completes: format pe, architecture x86_64, image base 0x140000000, 9 segments, 915 procedures, 635 strings. (c) How this differs from existing reports — so it is not read as a duplicate: - #527 (REA 3.2.1, closed): the authority gate was unconditional in committed code at that time. In 6.4.0 the gate is satisfied once the artifact is present, and (b) above shows a real successful run on Windows. - #3111 / #1701 / #2196 (open): those hosts have rea-windows-x64.node present and loading, and fail at the runtime self-test with Delete owned object by handle failed (Win32 5). Mine is a different failure — the artifact is absent entirely, reported as ENOENT, and no runtime self-test is ever reached. - If useful to those threads: my host (Windows 11 23H2, build 22631.4602, non-elevated, Defender only, %TEMP% on local NTFS C:) passes the native authority self-test and completes Ghidra analysis, which may help narrow the host-dependent factor under review in #2445. ### Typed outcome or recovery expected _No response_ ### Analysis or suspected cause _No response_ ### Additional context _No response_

bsakaguchi

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

closed this issue
added the
triage

bug
labels

bsakaguchi commented

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

Author

Owner

@pablodiazjorge commented on GitHub (Oct 14, 2026):

I reproduced this on Windows 11 with a source checkout: with native/windows/build/ empty, rea analyze rejects Ghidra as runtime_missing with only the ENOENT path. On current main, rea doctor --provider ghidra already reports ghidra-native_authority as missing_dependency, but its remediation only points to the published package. I'd like to take your option 2: name the missing artifact and both ways to get it (the published package, or the native build lane in native/windows/README.md) in the rejection and in doctor, without changing how the artifact is installed; option 1 changes the install contract, so I'd leave it to a maintainer. I'm at the open-PR limit, so I'll open the PR as soon as one of mine lands.

@pablodiazjorge commented on GitHub (Oct 14, 2026): I reproduced this on Windows 11 with a source checkout: with `native/windows/build/` empty, `rea analyze` rejects Ghidra as `runtime_missing` with only the ENOENT path. On current main, `rea doctor --provider ghidra` already reports `ghidra-native_authority` as `missing_dependency`, but its remediation only points to the published package. I'd like to take your option 2: name the missing artifact and both ways to get it (the published package, or the native build lane in `native/windows/README.md`) in the rejection and in `doctor`, without changing how the artifact is installed; option 1 changes the install contract, so I'd leave it to a maintainer. I'm at the open-PR limit, so I'll open the PR as soon as one of mine lands.

bsakaguchi commented

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

Author

Owner

@Jackzigen commented on GitHub (Oct 14, 2026):

I hit the same wall setting up a source checkout on Windows and traced the gap:

native/windows/build/ is gitignored by design (the README documents the Linux cross-compile lane), and nothing in the source-install path fetches the published artifact, so every provider is rejected at loadWindowsNativeAuthority with a bare ENOENT ... manifest.json.
The artifact already ships in the npm tarball (package/native/windows/build/{manifest.json, rea-windows-x64.node}), and the loader already validates package version, ABI, PE architecture, and SHA-256 before loading — so a fetch step that places those two files from the published tarball is safe by construction: the manifest still has to match the running version and hash out.

Unless someone is already on it, I'd like to take this with a two-part fix:

rea setup (and the documented install flow) gains a step that detects an empty native/windows/build/ on win32 and fetches the matching-version tarball from the npm registry, extracting only those two files. Offline/fetch-failure leaves today's behaviour untouched.
The loader's ENOENT branch stops reporting a raw filesystem error and instead names the missing artifact and the one command that fixes it, so rea doctor output and the provider_unavailable rejection both point at the recovery path instead of unsupported_host + ENOENT.

Will link the PR here once it's up.

@Jackzigen commented on GitHub (Oct 14, 2026): I hit the same wall setting up a source checkout on Windows and traced the gap: - `native/windows/build/` is gitignored by design (the README documents the Linux cross-compile lane), and nothing in the source-install path fetches the published artifact, so every provider is rejected at `loadWindowsNativeAuthority` with a bare `ENOENT ... manifest.json`. - The artifact already ships in the npm tarball (`package/native/windows/build/{manifest.json, rea-windows-x64.node}`), and the loader already validates package version, ABI, PE architecture, and SHA-256 before loading — so a fetch step that places those two files from the published tarball is safe by construction: the manifest still has to match the running version and hash out. Unless someone is already on it, I'd like to take this with a two-part fix: 1. `rea setup` (and the documented install flow) gains a step that detects an empty `native/windows/build/` on win32 and fetches the matching-version tarball from the npm registry, extracting only those two files. Offline/fetch-failure leaves today's behaviour untouched. 2. The loader's ENOENT branch stops reporting a raw filesystem error and instead names the missing artifact and the one command that fixes it, so `rea doctor` output and the `provider_unavailable` rejection both point at the recovery path instead of `unsupported_host` + ENOENT. Will link the PR here once it's up.

bsakaguchi commented

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

Author

Owner

@pablodiazjorge commented on GitHub (Oct 14, 2026):

@Jackzigen I have part 2 ready (the loader names the missing artifact and both recovery paths, and rea doctor gets a matching remediation), and I'll open it as soon as one of my PRs lands. Part 1 changes the install flow, so I'd leave that one to you if you want it.

@pablodiazjorge commented on GitHub (Oct 14, 2026): @Jackzigen I have part 2 ready (the loader names the missing artifact and both recovery paths, and `rea doctor` gets a matching remediation), and I'll open it as soon as one of my PRs lands. Part 1 changes the install flow, so I'd leave that one to you if you want it.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Delivered on main in fffb07419.

Missing source-checkout native files surfaced raw read failures without the matching-version recovery path. Native artifact loading now distinguishes missing packaging from host self-test failure and explains recovery without downloading or weakening authority.

Validation: WindowsNativeLoader tests and the hosted Windows capability/package lane. Full exact-revision qualification passed.

@morluto commented on GitHub (Oct 14, 2026): Delivered on main in [fffb07419](https://github.com/morluto/rea/commit/fffb0741936067530d1ce9777461cd53e87398c2). Missing source-checkout native files surfaced raw read failures without the matching-version recovery path. Native artifact loading now distinguishes missing packaging from host self-test failure and explains recovery without downloading or weakening authority. Validation: WindowsNativeLoader tests and the hosted Windows capability/package lane. Full exact-revision [qualification](https://github.com/morluto/rea/actions/runs/38629313022) passed.

bsakaguchi referenced this issue

2026-10-17 21:10:14 +00:00

[PR #1305] [MERGED] chore(release/6.2.0): release rea-agents 6.2.0 #2786

bsakaguchi referenced this issue

2026-10-17 21:10:30 +00:00

[PR #1340] [MERGED] chore(release): sync 6.2.0 checkpoint into main #2808