morluto/rea

Fork 0

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

[GH-ISSUE #4948] `recover_javascript_sources` is Linux-x64-gated even though Wakaru ships a native darwin-arm64 build #3067

New issue

Open

opened 2026-10-31 00:35:51 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

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

Owner

Originally created by @cbnwtzvgf4-oss on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4948

What happens

recover_javascript_sources is permanently unavailable on macOS. It fails with a capability-unavailable error before any work starts, even when a fully working Wakaru binary is present on the machine.

binary_session reports the javascript-recovery group as unavailable, consistent with the throw below.

Root cause

In rea-agents@6.5.0, dist/mcp/main-*.js gates the capability on the host platform:

if (process.platform !== "linux" || process.arch !== "x64" || configured === undefined || !isAbsolute(configured))
    throw new AnalysisCapabilityUnavailableError("wakaru", ...);

On darwin-arm64 this always throws, regardless of what REA_WAKARU_COMMAND points to.

Why the gate looks too strict

The tool contract says "caller-supplied Wakaru ^1.13.0 (verified with 1.14.0) on Linux x64", but Wakaru itself is not Linux-only. The published npm package ships a native darwin-arm64 build:

$ npm i wakaru@1.14.0
added 3 packages in 2s

$ cat node_modules/@wakaru/cli-darwin-arm64/package.json
{ "name": "@wakaru/cli-darwin-arm64", "version": "1.14.0", "os": ["darwin"], "cpu": ["arm64"] }

$ file node_modules/@wakaru/cli-darwin-arm64/wakaru
Mach-O 64-bit executable arm64

$ ./node_modules/.bin/wakaru --version
wakaru 1.14.0

$ ./node_modules/.bin/wakaru zip-fs.min.js -o /tmp/out
# real 0m0.123s — 197,554 B minified -> 405,007 B deobfuscated

So the restriction appears to mean "only verified on Linux x64", not "only functions on Linux x64".

Environment

rea-agents 6.5.0 (npm package, MCP over stdio)
Node v26.7.0
macOS 27.0.1, arm64
Wakaru 1.14.0 from npm (@wakaru/cli + @wakaru/cli-darwin-arm64)

Suggested change

Relax the host-platform gate so a caller-supplied REA_WAKARU_COMMAND is accepted on any platform (caller takes responsibility for the binary).
Or keep Linux as the default but allow an explicit per-platform allowlist (darwin-arm64 / darwin-x64) once verified, reported through a config/env override.
If a specific Wakaru build is genuinely required, surface that as a limitations entry on the capability instead of making the whole operation unavailable.

Happy to test a patched build on darwin-arm64 (both recover_javascript_sources end-to-end and the evidence/digest output) and report results here.

Originally created by @cbnwtzvgf4-oss on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4948 ## What happens `recover_javascript_sources` is permanently unavailable on macOS. It fails with a capability-unavailable error before any work starts, even when a fully working Wakaru binary is present on the machine. `binary_session` reports the javascript-recovery group as unavailable, consistent with the throw below. ## Root cause In `rea-agents@6.5.0`, `dist/mcp/main-*.js` gates the capability on the **host** platform: ```js if (process.platform !== "linux" || process.arch !== "x64" || configured === undefined || !isAbsolute(configured)) throw new AnalysisCapabilityUnavailableError("wakaru", ...); ``` On darwin-arm64 this always throws, regardless of what `REA_WAKARU_COMMAND` points to. ## Why the gate looks too strict The tool contract says "caller-supplied Wakaru ^1.13.0 (verified with 1.14.0) on Linux x64", but Wakaru itself is not Linux-only. The published npm package ships a native darwin-arm64 build: ``` $ npm i wakaru@1.14.0 added 3 packages in 2s $ cat node_modules/@wakaru/cli-darwin-arm64/package.json { "name": "@wakaru/cli-darwin-arm64", "version": "1.14.0", "os": ["darwin"], "cpu": ["arm64"] } $ file node_modules/@wakaru/cli-darwin-arm64/wakaru Mach-O 64-bit executable arm64 $ ./node_modules/.bin/wakaru --version wakaru 1.14.0 $ ./node_modules/.bin/wakaru zip-fs.min.js -o /tmp/out # real 0m0.123s — 197,554 B minified -> 405,007 B deobfuscated ``` So the restriction appears to mean "only verified on Linux x64", not "only functions on Linux x64". ## Environment - rea-agents 6.5.0 (npm package, MCP over stdio) - Node v26.7.0 - macOS 27.0.1, arm64 - Wakaru 1.14.0 from npm (`@wakaru/cli` + `@wakaru/cli-darwin-arm64`) ## Suggested change 1. Relax the host-platform gate so a caller-supplied `REA_WAKARU_COMMAND` is accepted on any platform (caller takes responsibility for the binary). 2. Or keep Linux as the default but allow an explicit per-platform allowlist (darwin-arm64 / darwin-x64) once verified, reported through a config/env override. 3. If a specific Wakaru build is genuinely required, surface that as a `limitations` entry on the capability instead of making the whole operation unavailable. Happy to test a patched build on darwin-arm64 (both `recover_javascript_sources` end-to-end and the evidence/digest output) and report results here.

bsakaguchi commented

2026-10-31 00:35:52 +00:00

Author

Owner

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

Thanks for the thorough root-cause write-up. The evidence is convincing: Wakaru ships a native darwin-arm64 binary and deobfuscation works fine there, so gating on process.platform/arch is over-restrictive — it turns "verified on Linux x64" into "unavailable everywhere else".

My suggestion: make the gate capability-driven rather than platform-driven. Keep a verified-platform allowlist for the "fully verified" path, but on other platforms fall through to whatever REA_WAKARU_COMMAND resolves to and report capability as "unverified" instead of throwing AnalysisCapabilityUnavailableError — or at minimum, allow darwin-arm64 explicitly since the npm package clearly supports it. That keeps the conservative default while not blocking users who already have a working Wakaru binary.

@XinwangTao commented on GitHub (Oct 18, 2026): Thanks for the thorough root-cause write-up. The evidence is convincing: Wakaru ships a native darwin-arm64 binary and deobfuscation works fine there, so gating on process.platform/arch is over-restrictive — it turns "verified on Linux x64" into "unavailable everywhere else". My suggestion: make the gate capability-driven rather than platform-driven. Keep a verified-platform allowlist for the "fully verified" path, but on other platforms fall through to whatever REA_WAKARU_COMMAND resolves to and report capability as "unverified" instead of throwing AnalysisCapabilityUnavailableError — or at minimum, allow darwin-arm64 explicitly since the npm package clearly supports it. That keeps the conservative default while not blocking users who already have a working Wakaru binary.

bsakaguchi commented

2026-10-31 00:35:53 +00:00

Author

Owner

@cbnwtzvgf4-oss commented on GitHub (Oct 18, 2026):

Implemented the capability-driven gate and opened #4958.

What changed:

resolveWakaruCommand() no longer requires process.platform === "linux" && process.arch === "x64"; it only requires an absolute REA_WAKARU_COMMAND. Host verification is reported, not enforced.
createServer enables javascriptRecovery from the configured command rather than linuxX64.
CapabilityInventory / tool description / docs/javascript-recovery.md now say Linux x64 is the only fully verified host and other hosts are unverified.
The two wakaruCommandConfiguration tests are no longer skipped off-Linux — they pass on darwin-arm64.

End-to-end verification on darwin-arm64 (macOS 27.0.1), npm @wakaru/cli-darwin-arm64 1.14.0:

recover_javascript_sources(react-dom 18.3.1 production.min.js)
input 131,685 B -> exit 0, provider wakaru 1.14.0, 1 module decompiled / 0 failed, 180 ms
output 309,106 B module + 183,126 B source map, readable ES module text

Before the change the same call throws AnalysisCapabilityUnavailableError.

One thing worth deciding in review: macOS has no ulimit -v, so the 1 GiB address-space ceiling is not enforceable there. The PR keeps REA_JAVASCRIPT_PRLIMIT_COMMAND as the hook and documents a wrapper; the alternative is to require that variable on unverified hosts and keep throwing when it is absent. Either is fine on my side.

@cbnwtzvgf4-oss commented on GitHub (Oct 18, 2026): Implemented the capability-driven gate and opened #4958. What changed: - `resolveWakaruCommand()` no longer requires `process.platform === "linux" && process.arch === "x64"`; it only requires an absolute `REA_WAKARU_COMMAND`. Host verification is reported, not enforced. - `createServer` enables `javascriptRecovery` from the configured command rather than `linuxX64`. - `CapabilityInventory` / tool description / `docs/javascript-recovery.md` now say Linux x64 is the only *fully verified* host and other hosts are unverified. - The two `wakaruCommandConfiguration` tests are no longer skipped off-Linux — they pass on darwin-arm64. End-to-end verification on darwin-arm64 (macOS 27.0.1), npm `@wakaru/cli-darwin-arm64` 1.14.0: ``` recover_javascript_sources(react-dom 18.3.1 production.min.js) input 131,685 B -> exit 0, provider wakaru 1.14.0, 1 module decompiled / 0 failed, 180 ms output 309,106 B module + 183,126 B source map, readable ES module text ``` Before the change the same call throws `AnalysisCapabilityUnavailableError`. One thing worth deciding in review: macOS has no `ulimit -v`, so the 1 GiB address-space ceiling is not enforceable there. The PR keeps `REA_JAVASCRIPT_PRLIMIT_COMMAND` as the hook and documents a wrapper; the alternative is to require that variable on unverified hosts and keep throwing when it is absent. Either is fine on my side.

bsakaguchi commented

2026-10-31 00:35:53 +00:00

Author

Owner

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

On the review question I'd lean toward option 1 (keep REA_JAVASCRIPT_PRLIMIT_COMMAND as the documented hook, no hard requirement). The whole point of the capability-driven gate is that the caller takes responsibility for the binary, and re-introducing a mandatory env var on unverified hosts recreates the same "unavailable without a reason" experience — just moved from platform to environment. The address-space ceiling is a safety rail, not a behavior contract, so documenting the wrapper and emitting a one-time warning when the var is absent on a non-Linux host gives the guardrail without a hard block. If stricter enforcement is ever needed, an opt-in flag (e.g. REA_REQUIRE_WAKARU_PRLIMIT=1) keeps it explicit rather than the default.

@XinwangTao commented on GitHub (Oct 18, 2026): On the review question I'd lean toward option 1 (keep REA_JAVASCRIPT_PRLIMIT_COMMAND as the documented hook, no hard requirement). The whole point of the capability-driven gate is that the caller takes responsibility for the binary, and re-introducing a mandatory env var on unverified hosts recreates the same "unavailable without a reason" experience — just moved from platform to environment. The address-space ceiling is a safety rail, not a behavior contract, so documenting the wrapper and emitting a one-time warning when the var is absent on a non-Linux host gives the guardrail without a hard block. If stricter enforcement is ever needed, an opt-in flag (e.g. REA_REQUIRE_WAKARU_PRLIMIT=1) keeps it explicit rather than the default.

bsakaguchi commented

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

Author

Owner

@cbnwtzvgf4-oss commented on GitHub (Oct 18, 2026):

Option 1 is implemented as of 4b318b5 — the limiter is now resolved three-valued (enforced / unknown / unenforced), a missing limiter on non-Linux degrades the call with a one-time warning instead of blocking it, and Linux behavior is untouched. Details and the verification notes are on #4958.

@cbnwtzvgf4-oss commented on GitHub (Oct 18, 2026): Option 1 is implemented as of `4b318b5` — the limiter is now resolved three-valued (`enforced` / `unknown` / `unenforced`), a missing limiter on non-Linux degrades the call with a one-time warning instead of blocking it, and Linux behavior is untouched. Details and the verification notes are on #4958.

bsakaguchi referenced this issue

2026-10-31 01:07:51 +00:00

[PR #3077] [CLOSED] fix(session): report adb, apktool, and jeb readiness #5596

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3067

No description provided.

Rows
Columns

[GH-ISSUE #4948] recover_javascript_sources is Linux-x64-gated even though Wakaru ships a native darwin-arm64 build #3067

What happens

Root cause

Why the gate looks too strict

Environment

Suggested change

[GH-ISSUE #4948] `recover_javascript_sources` is Linux-x64-gated even though Wakaru ships a native darwin-arm64 build #3067