morluto/rea

Fork 0

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

[GH-ISSUE #2128] [Bug] analyze-javascript-application: every ASAR input misreported as ENOENT on Windows (directory input works) #696

New issue

Closed

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

bsakaguchi commented

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

Owner

Originally created by @zhu-yan42 on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2128

Summary

On Windows, rea analyze-javascript-application <path-to.asar> fails with input_path ENOENT ("No file or directory exists at the selected input path") for every ASAR input — including a freshly packed 590-byte ASAR whose existence is trivially verifiable. Directory input works end-to-end, so the defect is specific to the ASAR input branch.

Environment

REA: 6.4.0 (npm install --global rea-agents)
Node.js: v24.21.0, npm 11.12.1
OS: Windows 11 (x64)
Shells tested: Git Bash (npm shell shim) and cmd.exe (via rea.cmd) — identical behavior

Minimal reproduction

mkdir tiny-app
printf '{"name":"tiny","main":"index.js"}' > tiny-app/package.json
printf 'const x = 1;\nmodule.exports = { x };\n' > tiny-app/index.js

# Directory input: works (rc=0, full evidence envelope)
rea analyze-javascript-application "C:/work/tiny-app" --json

# Pack the same directory, then analyze the ASAR: fails
npx -y @electron/asar pack tiny-app tiny.asar   # 590 bytes, verified on disk
rea analyze-javascript-application "C:/work/tiny.asar" --json

Observed error (trimmed):

{
  "error": "JavaScript application analysis failed",
  "code": "invalid_request",
  "details": {
    "operation": "analyze_javascript_application",
    "issues": [{
      "path": ["input_path"],
      "reason": "invalid_value",
      "message": "No file or directory exists at the selected input path (ENOENT): C:/work/tiny.asar"
    }]
  }
}

The file exists and is readable (Get-Item / stat confirm size and content) at the exact path echoed in the error.

Variants excluded

Backslash vs forward-slash paths — both fail
Pure-ASCII path (real target was C:\Users\...\Kimi\resources\app.asar, 121 MB) — same ENOENT
Copying the ASAR to a different directory — same ENOENT
cmd.exe direct invocation (bypassing the Git Bash npm shim) — same ENOENT

So this is not a path-encoding, shell-shim, or permission issue; the ASAR branch's existence check (or an early read wrapped as ENOENT) appears to be at fault.

Expected behavior

ASAR input is analyzed as documented ("Inspect an extracted JavaScript/Electron app directory or ASAR"), or — if ASAR validation genuinely fails — the error should name the real cause instead of ENOENT.

Workaround

npx -y @electron/asar extract app.asar app-extracted
rea analyze-javascript-application "C:/path/to/app-extracted" --json

Verified: a 121 MB Electron app ASAR analyzes cleanly this way (440 JS files, 10.3M AST nodes, 10,243 findings, full Electron surface summary).

Happy to test a fix or provide the exact repro artifacts.

Originally created by @zhu-yan42 on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2128 ## Summary On Windows, `rea analyze-javascript-application <path-to.asar>` fails with `input_path` ENOENT ("No file or directory exists at the selected input path") for **every** ASAR input — including a freshly packed 590-byte ASAR whose existence is trivially verifiable. Directory input works end-to-end, so the defect is specific to the ASAR input branch. ## Environment - REA: 6.4.0 (`npm install --global rea-agents`) - Node.js: v24.21.0, npm 11.12.1 - OS: Windows 11 (x64) - Shells tested: Git Bash (npm shell shim) and `cmd.exe` (via `rea.cmd`) — identical behavior ## Minimal reproduction ```bash mkdir tiny-app printf '{"name":"tiny","main":"index.js"}' > tiny-app/package.json printf 'const x = 1;\nmodule.exports = { x };\n' > tiny-app/index.js # Directory input: works (rc=0, full evidence envelope) rea analyze-javascript-application "C:/work/tiny-app" --json # Pack the same directory, then analyze the ASAR: fails npx -y @electron/asar pack tiny-app tiny.asar # 590 bytes, verified on disk rea analyze-javascript-application "C:/work/tiny.asar" --json ``` Observed error (trimmed): ```json { "error": "JavaScript application analysis failed", "code": "invalid_request", "details": { "operation": "analyze_javascript_application", "issues": [{ "path": ["input_path"], "reason": "invalid_value", "message": "No file or directory exists at the selected input path (ENOENT): C:/work/tiny.asar" }] } } ``` The file exists and is readable (`Get-Item` / `stat` confirm size and content) at the exact path echoed in the error. ## Variants excluded - Backslash vs forward-slash paths — both fail - Pure-ASCII path (real target was `C:\Users\...\Kimi\resources\app.asar`, 121 MB) — same ENOENT - Copying the ASAR to a different directory — same ENOENT - `cmd.exe` direct invocation (bypassing the Git Bash npm shim) — same ENOENT So this is not a path-encoding, shell-shim, or permission issue; the ASAR branch's existence check (or an early read wrapped as ENOENT) appears to be at fault. ## Expected behavior ASAR input is analyzed as documented ("Inspect an extracted JavaScript/Electron app directory or ASAR"), or — if ASAR validation genuinely fails — the error should name the real cause instead of ENOENT. ## Workaround ```bash npx -y @electron/asar extract app.asar app-extracted rea analyze-javascript-application "C:/path/to/app-extracted" --json ``` Verified: a 121 MB Electron app ASAR analyzes cleanly this way (440 JS files, 10.3M AST nodes, 10,243 findings, full Electron surface summary). Happy to test a fix or provide the exact repro artifacts.

bsakaguchi

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

closed this issue
added the
P1: high

area: domain

bug
labels

bsakaguchi commented

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

Author

Owner

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

Hi! I'd like to work on this. I'll trace the ASAR input branch of analyze_javascript_application to find where a valid Windows path gets reported as ENOENT, add a regression test for Windows-style paths, and make sure real ASAR validation failures report their actual cause. I'll open a PR referencing this issue.

@maxiaochaos commented on GitHub (Oct 12, 2026): Hi! I'd like to work on this. I'll trace the ASAR input branch of `analyze_javascript_application` to find where a valid Windows path gets reported as ENOENT, add a regression test for Windows-style paths, and make sure real ASAR validation failures report their actual cause. I'll open a PR referencing this issue.

bsakaguchi commented

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

Author

Owner

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

Verified on current main (7ae3c50a) from source on Windows 11 (x64, Node 24.18.0): the ASAR input branch works correctly.
ode scripts/rea.mjs analyze-javascript-application tiny.asar --json completes end-to-end with a full Evidence envelope (2 files, 1 finding, format=asar). This appears to have been fixed by one of the merged ASAR changes since 6.4.0 (likely #582, #583, #1055, or #1400). The issue may be closable once a release includes those fixes.

@chqcjq commented on GitHub (Oct 12, 2026): Verified on current main (7ae3c50a) from source on Windows 11 (x64, Node 24.18.0): the ASAR input branch works correctly. ode scripts/rea.mjs analyze-javascript-application tiny.asar --json completes end-to-end with a full Evidence envelope (2 files, 1 finding, format=asar). This appears to have been fixed by one of the merged ASAR changes since 6.4.0 (likely #582, #583, #1055, or #1400). The issue may be closable once a release includes those fixes.

bsakaguchi commented

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

Author

Owner

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

Thanks for verifying on Windows! Since ASAR works on current main after the 6.4.0+ fixes, I’ll close my diagnostic PR and won’t pursue a fix here. Happy to help if a release still shows the ENOENT on someone’s setup.

@maxiaochaos commented on GitHub (Oct 13, 2026): Thanks for verifying on Windows! Since ASAR works on current main after the 6.4.0+ fixes, I’ll close my diagnostic PR and won’t pursue a fix here. Happy to help if a release still shows the ENOENT on someone’s setup.

bsakaguchi commented

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

Author

Owner

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

Closing based on the Windows 11 / Node 24 contributor verification at 7ae3c50a, which is contained in current main. The diagnostic PR was subsequently abandoned after that successful end-to-end ASAR run. The tiny ASAR workflow also succeeds on macOS in this audit; I did not independently rerun Windows.

@morluto commented on GitHub (Oct 14, 2026): Closing based on the [Windows 11 / Node 24 contributor verification](https://github.com/morluto/rea/issues/2128#issuecomment-6127273085) at [7ae3c50a](https://github.com/morluto/rea/commit/7ae3c50a), which is contained in current main. The diagnostic PR was subsequently abandoned after that successful end-to-end ASAR run. The tiny ASAR workflow also succeeds on macOS in this audit; I did not independently rerun Windows.

bsakaguchi referenced this issue

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

[PR #696] [MERGED] fix(reference): distinguish computed require member names #2176

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#696

No description provided.

Rows
Columns