Inspect an Electron app's behavior with REA

REA can map a local JavaScript or Electron application from files you are authorized to inspect, even when you do not have its source tree. The useful outcome is an evidence trail for one behavior: which module exposes it, where a call crosses a process boundary, and which parts still need a separate check. This guide uses the REA project's current documentation, checked on October 14, 2026. BIG CHANGE did not run REA on an application.

The big change

• What changed: REA gives a coding agent a structured map of modules, imports, source maps, routes and Electron IPC from a supplied app directory or ASAR. Each finding can point back to the files that produced it.
• Why it matters: A developer investigating one feature can follow a named API or IPC channel through the packaged app before deciding what to inspect manually. That makes the question narrower and the evidence easier to check.
• What to watch: Static code paths are candidates, not proof that the app takes them during use. A claim about a specific behavior still needs an independent observation or test on the authorized target.

Before you start

This walkthrough is for a developer who owns a local JavaScript or Electron app, or has permission to inspect it. You need the extracted application directory or its app.asar file and an absolute path to it. REA's package manifest lists rea-agents version 6.4.0 and requires Node.js 22.19 or later within the 22.x line, 24.11 or later within 24.x, or 26 and later. You also need npm. On Linux, REA's static JavaScript/Electron analysis also requires a procps-compatible ps on REA's PATH for process-ownership checks, as its installation guide explains. These are REA host requirements, separate from whatever the target app needs to run.

The static JavaScript workflow needs no Hopper, Ghidra, IDA, browser or running Electron process. Those tools belong to other REA workflows. Check your rights to inspect the target and keep a copy of the original files so you can identify exactly which artifact produced a result. Use the official morluto/rea repository or its linked npm package for installation; a similarly named repository does not establish provenance.

1. Set up REA or use the one-off CLI

For a connected coding agent, the documented setup command is:

npx rea-agents setup

Review the changes it proposes to your agent configuration, approve the ones you want, then restart the agent. If you only need a terminal inspection, the documented command below invokes the package for that run. @latest selects the release current when you execute it; record the resolved version with your evidence because output details may change. The 6.4.0 version above is what the project manifest showed at this article's October 14 check.

2. Analyze the supplied files

Replace the example path with the absolute path to your authorized app folder or ASAR:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json

The CLI guide warns that complete Evidence can be very large. Save it as a file, then read a summary or selected module view. Avoid pasting the whole result into a prompt. If the command fails, keep the error and target path for diagnosis; a zero exit status can still come with partial coverage, warnings or unresolved findings. On Windows, the README shows a path such as "D:/apps/example".

The artifact reconstruction reference says this operation reads the selected files as data without executing the app. It inventories artifact paths and digests, parses available JavaScript and TypeScript, and reports candidate entrypoints, imports, source maps, routes, network endpoints, Electron preload and renderer links, contextBridge APIs, IPC calls and handlers, and native add-on requests. The expected result is an Evidence record with a graph, static Electron summary, coverage and limitations. A reported .node binding is a relationship to inspect, not a decoding of that native module.

3. Follow one narrow feature

Choose a feature with a name you can locate, such as a menu action or exposed API method. Record its user-facing name and search the REA result for the corresponding module, literal IPC channel or route. Follow the reported source locations in order: renderer or page call, preload bridge, IPC transmission, matching main-process handler, then the file or service operation the handler invokes. REA's Electron CSV example demonstrates this pattern with notes.exportCsv(), the notes:export channel and a main-process writer. Those names belong to the sample app; your target will have different names.

For each link, note the artifact digest, file path, location and what the code actually shows. Distinguish a literal channel paired to one handler from a computed channel or ambiguous pairing. Check the coverage and limitations fields before treating a missing module or handler as absent. REA says malformed or unavailable files, missing ASAR companion bytes, unresolved expressions and bounded analysis can leave relationships unknown. A source map can expose original source names, but the tool does not promise the original source tree.

4. Check the behavior independently

Write one falsifiable claim from the static trail, such as “this action invokes this channel and the handler writes this type of file.” Then use an approved test environment to perform only that action and observe the result directly: the created file, a changed state, or a trace collected under your own permissions. Record the app version, artifact digest, test steps and observed result. If running the app is outside your authorization, leave the claim at the level of a static code path. REA's example explicitly says its inferred path can be checked by runtime capture; its static graph alone does not show which branch ran.

You have succeeded when another developer can identify the same source locations, see the limits of the static pairing and repeat your narrow check. A successful analysis command by itself does not verify runtime behavior or establish a faithful reimplementation of the app.

If the result is incomplete

First check that the path points to a complete extracted directory or ASAR and that any needed .asar.unpacked companion files are present. Review REA's coverage and diagnostics; a missing or failed source is an unknown, not a negative finding. For a large app, the reference documents exact --source-path selections, though unselected files then remain outside analysis scope. If a literal IPC match is ambiguous or the channel is computed, inspect the cited files and narrow the question. Keep the ambiguity in the final notes if it remains.

REA's code is MIT licensed, but the target software and any external analysis engine retain their own licenses and terms. Static analysis processes target files locally. If you pass REA's findings to a coding agent, that model provider has its own data policy; avoid sending secrets or proprietary output until your organization has cleared that use. Check the terms and costs of your agent and any optional engine before use. The procedure and package version here were checked on October 14, 2026 and are documentation based.