REA Setup Not Working?
5 Common Errors and Fixes

If REA won't install or your agent can't see it, you're in the right place. This page starts from the error you already got, not from a clean install. Setup rarely fails for an interesting reason: in practice it fails for one of five, and four of them are about your machine rather than REA itself. Find your symptom in the triage table, then read that section.

First move: two read-only commands

Before you change anything, run REA's own diagnosis. Both commands are read-only — they change nothing on your machine — so they are the fastest way to localize the fault.

1. doctor — diagnose clients, providers and installed skill files (strictly read-only):

# check one agent registration
npx rea-agents doctor --client claude_code --json
# check a native engine (or hopper / ida)
npx rea-agents doctor --provider ghidra --json
# check the installed workflow instructions
npx rea-agents doctor --skill --json

2. --dry-run — preview exactly what setup would write, without writing it:

npx -y rea-agents@latest setup --client codex --dry-run

Per the official installation guide, doctor --json is strictly read-only and setup --dry-run returns a plan with status planned instead of applying it. Two caveats the guide calls out: doctor checks files and prerequisites, not the live agent connection, so you still have to restart the agent yourself (3); and provider failures in doctor do not block the dependency-free targets (JavaScript and .NET).

The five common errors

1. EBADENGINE — wrong Node version

Symptom. npx rea-agents@latest setup fails before it does anything useful, or npm complains about an unsupported engine.

What's actually happening. REA requires Node.js 22 (22.19+), 24 (24.11+) or 26+. Two failures hide here: an old minor inside an otherwise correct major (22.4 instead of 22.19), and a version manager silently serving a different runtime than the one in your shell.

Fix. Check what you're actually running, not what you installed:

node -v

If it's outside those ranges, switch to a supported line (a version manager is the least painful route), then re-run the setup command in the same shell:

npx rea-agents@latest setup

Confirm it's fixed. node -v prints a supported version, and the setup command completes without a version error. If you use more than one runtime, re-run the setup under the runtime your agent will actually inherit.

2. "Running scripts is disabled" — PowerShell

Symptom. On Windows the install stops with a script-blocked or execution-policy message. Sometimes nothing runs at all after the command appears to start.

What's actually happening. PowerShell blocks scripts by default on many Windows setups, and npm's shims are scripts. This is a machine policy, not a REA bug — nothing about the project is broken.

Fix. Check the current policy, then relax it for the current user only (a scoped change, not a machine-wide one):

Get-ExecutionPolicy -List

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Then re-run the setup command. Prefer RemoteSigned over Unrestricted: it still blocks unsigned scripts that came from the internet.

Confirm it's fixed. The setup command runs to completion in the same PowerShell window. If your organisation manages policy centrally, this is a change your IT side has to make — don't fight it with per-session flags.

3. command not found: rea — server not registered

Symptom. One of two closely related failures: the terminal replies command not found: rea (or 'rea' is not recognized on Windows), or install reports success but your agent behaves as if REA doesn't exist — no tools, no awareness, or it improvises an answer instead of analyzing anything.

What's actually happening. There are two distinct causes:

• command not found means you used npx (which never puts a global rea binary on your PATH) and then typed rea. Either prefix one-off commands with npx -y rea-agents@latest, or install the binary once:
  Copy

  npm install --global rea-agents
  rea --help

• The agent can't see REA means REA is consumed through an agent, and the agent only finds it if the server entry is registered and the agent has been restarted since. Registering without restarting is the single most common version of this failure.

Fix, in order:

1. Run npx rea-agents@latest setup and finish it — don't abort when it asks about configuration.
2. Verify the registration with read-only doctor (substitute your client ID, e.g. codex, cursor, claude_code), then preview the repair without writing:
   Copy

   npx rea-agents doctor --client claude_code --json
   npx -y rea-agents@latest setup --client claude_code --dry-run

   If the dry-run shows the missing registration, run setup again without --dry-run and approve the changes.
3. Open your agent's configuration and confirm the REA server entry is actually present. If you maintain the config by hand, add it there and save.
4. Fully quit and reopen the agent — not just a new chat window. Menubar/tray processes count; quit them. (doctor cannot detect a live connection, so this restart is on you.)
5. Ask the agent something REA-specific (e.g. list the Electron targets it can see). An answer that ignores the tool means the restart didn't take effect.

Confirm it's fixed. The agent answers from REA's tools rather than from general knowledge, and lists the capabilities you expect.

4. "No provider available" — missing provider

Symptom. Install is fine, the agent sees REA, and then an actual analysis run ends with a provider-related error — often stating no provider is available, or that the requested engine isn't installed.

What's actually happening. Not every target is self-contained. REA's static JavaScript and .NET paths need nothing extra, but native binaries need one of Hopper, Ghidra or IDA. If you haven't installed one, the target type that depends on it can't run — that's a missing dependency, not a broken install.

Fix.

1. Decide whether your target needs a provider at all. If you're analyzing a .NET assembly (a .dll/.exe with CLI metadata), or a JavaScript/Electron app, you don't.
2. Confirm which engine REA actually detects with read-only doctor (use hopper or ida in place of ghidra as appropriate):
   Copy

   npx rea-agents doctor --provider ghidra --json

   A provider failure here does not block the dependency-free JavaScript and .NET targets.
3. If it does need a provider, install one of Hopper, Ghidra or IDA, under a licence you are entitled to hold — and note that a third-party bridge's open-source licence covers the bridge, not the commercial product behind it. Trials are usable only within their own terms, which often exclude automation. See Tool licences you must supply yourself.
4. Re-run the analysis and pass the provider explicitly if your invocation supports it.

Confirm it's fixed. The provider error is gone and the run returns evidence (metadata, disassembly, structure) instead of a refusal.

5. "Nothing to analyze" — wrong target

Symptom. Everything is installed. The analysis refuses, reports nothing admitted, or comes back empty and confident about it.

What's actually happening. Two different mistakes produce the same silence:

• Wrong tool for the artifact. You pointed a native-binary path at a managed assembly, or expected a self-extracting single-file host to be unpacked for you — the static .NET path does not unpack single-file hosts.
• Wrong artifact entirely. What you downloaded isn't the thing you wanted: a launcher stub instead of the real binary, a bundle instead of the module, a build without metadata.

Fix.

1. Identify what the file actually is before analyzing it — file type, size, and whether it carries the metadata your target type expects.
2. Match artifact to capability: JavaScript/Electron and .NET assemblies are static and dependency-free; native binaries need a provider; single-file hosts and IL2CPP-style builds need a different approach than the one you're trying.
3. If the artifact is a wrapper, find the real payload (installed directory, extracted bundle) and analyze that.

Confirm it's fixed. The run reports coverage and structure you can act on. If it reports a resource limit or partial coverage, that's a real result — read it as evidence, not as an error to retry.

After it works

Once REA runs, the answers you get are only as good as the questions: one behavior per question, absolute paths always. And before you act on any result, know what you're authorized to do with the target — start at Authorized use only.