REA setup and first-use guide

Documentation checked: 16 October 2026. This is a documentation-based guide, not a FollowAgents hands-on installation report. Repository main may describe capabilities absent from your installed npm release.

Start by separating three questions: what artifact will you inspect, can your agent discover REA, and is the required analysis engine available? This guide helps you locate the failing layer. For product selection, read our REA profile and limitations.

Choose a first task

Static inspection of an extracted JavaScript/Electron directory or ASAR does not require a native decompiler. Deep native analysis needs a suitable analysis engine, such as Ghidra, Hopper or IDA. REA connects the agent to analysis workflows; Ghidra is one possible engine. See the official project.

Connect your agent

Check node --version and npm --version. The documented Node.js versions are 22.x ≥22.19, 24.x ≥24.11, or 26+. Follow links from the official repository or rea.tools; the npm package is rea-agents.

npx rea-agents@latest setup

Select your client, review the proposed changes, and approve the intended configuration. Restart the client and enable MCP access where required. A finished package download does not establish that a live agent session can discover the tools. Follow the official setup guide.

Complete one small inspection

For a supplied JavaScript application directory or ASAR, the CLI offers a direct starting point:

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

Replace the path and choose your own output filename. Evidence can be large; save it and project a summary rather than pasting the entire result. See the CLI reference.

A suggested first agent request is: “Check which REA tools are available, identify this application's entry points and module relationships, cite the evidence, and list unresolved questions.” This is an editorial task template, not a tested outcome.

Diagnose the symptom before reinstalling

Separate command startup, registration, the current connection and provider prerequisites. These checks follow current documentation, not a ranking of fault frequency.

Node is installed, but REA rejects its version

node -v
npm -v

REA currently supports the Node 22 family from 22.19, the 24 family from 24.11, and 26+. Versions 23, 25 and prereleases are unsupported. An output such as 22.14 is too old: install a supported version, reopen the terminal and check again. An agent may inherit a different PATH; terminal success does not prove it uses the same runtime. See the official prerequisites.

Windows PowerShell blocks the npx script

The official guide provides a command-shim alternative:

npx.cmd rea-agents@latest setup

This addresses the PowerShell script-launch issue without globally disabling execution policy. Fully restart the client afterward and inspect its REA tool list. Native Windows analysis has separate platform requirements.

Setup finished, but the agent has no REA tools

Check the actual client, for example Codex:

npx -y rea-agents@latest doctor --client codex --json

Use the documented ID for another client. Expect a healthy check for that registration. Repair reported failures; if the check is healthy but the session has no tools, restart or reconnect the client and enable REA in its MCP settings. A valid registration does not prove the current chat is connected. A Skill instruction file is not an MCP connection.

REA works, but the Ghidra workflow fails

npx -y rea-agents@latest doctor --provider ghidra --json

Read the scoped failures, including Ghidra, JDK and path requirements. After setting paths, rerun setup so the client receives the environment, then restart it. If the result is ambiguous, inspect its candidates and choose explicitly; it does not mean no provider exists. A static JavaScript/Electron task does not require repairing Ghidra first.

Static analysis fails to compile a macOS helper

Our Electron case study encountered this in a restricted sandbox: the diagnosis pointed to an xcrun build failure for a process-ownership helper. Check command-line build tools, read the compiler error and confirm the environment allows the required local compilation. This differs from loading a Skill. Our run succeeded with normal compiler permissions; other build failures may have different causes.

The command wrote JSON; did it succeed?

Inspect error, code and remediation first. Partial observations inside a failure are not a completed analysis. For successful Evidence, check operation, coverage, limitations and the fields needed for your task. Keep the diagnosis and fix its cause before retrying. Full JSON can include local paths; review it before sharing.

Reference: official installation and diagnostics. To try direct CLI analysis independently of client setup, follow the five-file Electron static-analysis case.

Check native Windows support separately

Starting REA on Windows does not establish support for every native-analysis target. Check the platform, filesystem, JDK, Ghidra and target-format conditions in the Windows Ghidra guide, and distinguish the installed npm release from upstream main.

Review what the result establishes

Our editorial checklist is: identify the artifact, connect conclusions to evidence, and keep unknowns visible. Static inspection and runtime observations have different evidence boundaries; consult the application workflow reference.

Return to the REA profile to review suitability and limitations before choosing a deeper task.