REA MCP Setup: Install rea-agents for Claude Code, Cursor and Codex

Run npx rea-agents@latest setup, approve the plan it shows, then fully restart your coding agent. You need Node.js 22.19+, 24.11+ or 26+; nothing else is required for JavaScript/Electron and .NET analysis. REA (Reverse Engineer Anything) is a third-party open-source project (morluto/rea) that gives AI coding agents reverse-engineering tools over MCP; this site is not affiliated with it.

Commands and output below were checked against REA 6.7.0. When a flag here disagrees with rea --help on your machine, trust --help.

Prerequisites

The real package. REA is published on npm as rea-agents; it is never a standalone .exe or .dmg download. See how to verify a genuine REA install.

Node.js 22.19+, 24.11+ or 26+, plus npm. The 6.7.0 package.json declares "node": "^22.19.0 || ^24.11.0 || >=26.0.0", so Node.js 23, 25 and older 22.x/24.x releases are unsupported. REA never upgrades Node, npm or Homebrew for you.

Check what you have:

node -v
npm -v

If node -v prints an older version or “command not found”, install Node.js 24 LTS. The REA get-started page lists these options:

# Windows (PowerShell)
winget install OpenJS.NodeJS.LTS

# macOS with Homebrew
brew install node

# macOS / Linux without Homebrew: install fnm, reopen the terminal, then
curl -fsSL https://fnm.vercel.app/install | bash
fnm install 24
fnm default 24

Linux distribution nodejs packages are often older than 22.19, so check before blaming REA.

A coding agent that supports local MCP servers. Claude Code, Codex and Cursor are the common choices. Setup also knows Claude Desktop, Gemini CLI, Windsurf, VS Code, GitHub Copilot CLI, OpenCode, Qwen Code, Grok Build and others (see the table in step 2).

Optional: a native analysis engine. You only need Ghidra, Hopper or IDA when you analyze native binaries. Static JavaScript/Electron and .NET analysis work without one. You can add an engine later.

Step 1: Run setup

From any directory, run:

npx rea-agents setup

To be sure you get the newest published release instead of a cached or project-local copy, use the explicit tag:

npx rea-agents@latest setup

What happens, and why it is safe to run:

1. npm asks to download the package. This is npm’s own prompt. Approving it does not approve any changes from REA.
2. REA shows a multi-select of supported agents. Existing REA registrations are pre-selected. Newly detected clients are listed but not selected; detection is context, not permission.
3. REA shows a plan. It lists each agent configuration path it will touch, each skill destination, any external software, and, if you choose it, a Hopper installation. Nothing is written until you approve.
4. REA applies the plan. Config writes keep unrelated entries and comments, create a .rea.backup, replace files atomically and verify the result.
5. Restart the agents named in the completion message.

Setup does two things per agent: it adds REA’s MCP server entry, and it installs REA’s bundled workflow skill (investigation instructions for the agent). For Claude Code the skill goes to ~/.claude/skills (or $CLAUDE_CONFIG_DIR/skills); most other clients use ~/.agents/skills. If you only want the MCP server, add --skill=false.

Setup also pins the registration to the exact REA version that ran it. Run through npx, 6.7.0 writes this (a dry run printed Command: "npx" "-y" "[email protected]" "mcp"):

{
  "mcpServers": {
    "rea": {
      "command": "npx",
      "args": ["-y", "[email protected]", "mcp"]
    }
  }
}

Run from a global or project install instead, the registration points at that rea executable’s absolute path with the argument mcp. Either way your agent does not silently pick up a new REA release; you upgrade deliberately (step 3). For Codex and Grok Build, setup also adds startup_timeout_sec = 30.

Restarting correctly

“Restart” means a full restart. For terminal agents (Claude Code, Codex, Gemini CLI), exit the session and start a new one. For desktop apps (Cursor, Claude Desktop, Windsurf, VS Code), quit the app completely. On macOS press ⌘Q. Closing the window is not enough. An agent that was running during setup will not see the new server until it reconnects.

Letting the agent run setup

If you prefer, paste this into your agent. It is the prompt the REA website suggests:

Install REA and connect it to this coding agent using npx rea-agents@latest setup.
Show me the setup plan for approval, then verify the installation.

The agent runs the same command and should show you the plan before approving anything. Read the plan yourself; do not let the agent approve it for you.

Step 2: Target specific agents (Claude Code, Cursor, Codex)

Interactive selection is fine for a laptop. For scripts, dotfiles or reproducible machines, name the clients explicitly with repeatable --client flags. An explicit client skips the interactive question.

Preview a plan for Codex and Cursor without writing anything:

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

--dry-run returns status planned with exit code 0 and lists each file it would touch; on macOS that was ~/.codex/config.toml, ~/.cursor/mcp.json and the skill at ~/.agents/skills/reverse-engineer-anything. Drop --dry-run to apply. Common client IDs (6.7.0 knows 25, including devin, kimi, trae and dsh; see the supported agents table):

For unattended runs, --yes approves the plan, but only within an explicit scope. Pair it with --client (or --all-detected if you really mean every detected client). Without a scope flag, --yes only refreshes existing REA registrations. Add --json for machine-readable output:

npx rea-agents@latest setup --client claude_code --yes --json

Clients setup does not know

Any client that can launch a local stdio MCP server can use REA. Add the same pinned entry shown above to its MCP configuration. REA is also listed in the MCP Registry as io.github.morluto/rea, so clients with Registry discovery can find it there.

Step 3: Optional global CLI, and how to keep it updated

npx is enough for agent use. If you also want a rea command in your shell, install it globally:

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

Note that npm install rea-agents without --global only puts rea in the current project’s node_modules/.bin. It will not be on your PATH, which is a common source of “rea: command not found”.

REA ships bug fixes often, so update regularly. For a global npm (or Bun) install:

rea update

rea update updates only the global installation that owns the running CLI, then checks the new executable’s version. It does not rewrite your agent registrations, which are still pinned to the old version. The update prints a scoped setup command; run it to review and approve the registration refresh, then restart your agents.

If you never installed globally and only use npx, refresh with:

npx rea-agents@latest setup

To check the newest published version without installing anything: npm view rea-agents dist-tags.latest.

Bun users can substitute bunx rea-agents@latest for npx rea-agents@latest. Bun global updates need Bun 1.2.17 or later.

To remove REA later, rea uninstall removes only REA-owned registrations and skill files, and rea uninstall --purge-data also clears REA’s cache and state under ~/.rea. Hopper, Node.js, your Evidence files and other MCP servers are left alone.

Step 4: See what REA can analyze with rea providers and rea capabilities

Before pointing REA at a native binary, ask it which engines it can actually use on this machine:

rea providers --json
rea capabilities --json

(Without a global install: npx -y rea-agents@latest providers --json.)

providers lists binary-session providers (Hopper, Ghidra, IDA) and the operations each supports. capabilities adds auxiliary capabilities. Together they answer “if I give REA this executable, who will analyze it?” They describe the CLI’s view; inside an agent, the connected server’s own tool list is the authority.

Provider selection follows simple rules:

• If exactly one available provider supports the target, REA uses it automatically.
• If several do, REA returns an ambiguous error with details.candidate_ids. Pick one with --provider ghidra (CLI) or provider_id on open_binary (MCP).
• Set REA_ANALYSIS_PROVIDER=ghidra for a standing preference. An explicit --provider still wins.

If you have none yet: Ghidra is free and covered in REA + Ghidra for native binaries. Hopper is commercial with a demo mode, and setup can install it after a separate approval. IDA is supported through an existing IDA MCP registration; see the IDA guide.

Step 5: Your first analysis

Start with something that needs no native engine: static analysis of a JavaScript or Electron app. REA reads the files without running the app, but your agent sends the results to its model provider, so analyze only software you own or are authorized to examine.

The REA website ships a tiny practice target for exactly this, a six-file Electron “notes” app with an Export notes button (first investigation walkthrough). Download https://rea.tools/examples/notes-example.zip, unzip it, then run:

rea analyze-javascript-application /absolute/path/to/notes-example --json > notes-evidence.json

Why redirect to a file: application Evidence can be large (the REA docs cite a 334 MB Evidence file for a real Electron app). Saving it lets you or your agent read projections of it instead of flooding a terminal. For a target directory or .asar, plain rea analyze PATH routes to the same workflow.

Now do the same through your agent. In Claude Code, Cursor or Codex, ask:

Use REA to inspect /absolute/path/to/notes-example and find what happens when
I click Export notes. Show where notes.csv is written, which fields it contains,
and the relevant files and lines.

A good answer traces the button from renderer.js, through a notes:export message in preload.js, to a handler in main.js that writes notes.csv to the Downloads folder. The handler shown on the REA site is:

ipcMain.handle("notes:export", () => {
  const destination = path.join(app.getPath("downloads"), "notes.csv");
  writeFileSync(destination, toCsv(notes), "utf8");
  return destination;
});

If the agent’s answer has no file and line references, ask for them. Evidence-backed answers are the point of REA, and the agent should separate what it observed from what it inferred.

When this works, you have verified the full chain: Node runtime, MCP registration, skill and REA’s analysis workflows.

Prompts that produce checkable answers

The skill handles tool routing, so a prompt does not need to list tools. Spend the words on the target, one concrete question, and what counts as “done”:

Use REA to analyze <absolute path to target>.
Question: <one concrete question about behaviour>.
For each conclusion, cite the REA Evidence ID it relies on, and label it as
an observation, an inference, or an unknown.
List what you could not determine and why.
Done means: <a check I can run myself>.

The Evidence ID and label lines make the agent separate what REA returned from what the model concluded. The “unknown” line gives it permission to say “not determined” instead of guessing, and a runnable “done” moves the final judgement to you.

Check that the agent really called REA

An answer that sounds like reverse engineering is not proof that REA ran:

1. Look at the tool calls in the transcript. Claude Code names MCP tools mcp__<server>__<tool>, so REA calls appear as mcp__rea__analyze_javascript_application, mcp__rea__open_binary and so on. If the transcript shows only shell calls to strings, objdump or xxd, the answer did not come from REA.
2. Check that the cited Evidence IDs exist. Ask the agent to call get_evidence_bundle with detail: "summary" for the current session and list them. An ID that is not in the session ledger was made up.
3. Run your “done” check yourself, for example by opening the cited file and line.

Troubleshooting

The agent does not see any REA tools. Almost always a restart issue. Fully quit and relaunch the client, then check its registration:

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

Swap codex for claude_code, cursor and so on. doctor checks files and prerequisites, not the live connection. Plain rea doctor also audits optional engines (Ghidra, IDA, JADX, Kuna) and reports unhealthy when they are missing; scope it with --client, --provider or --skill so the exit status reflects only what you use.

Wrong Node version in a GUI client. Version managers (fnm, nvm) can give a desktop app a different PATH than your terminal, so the npx it launches may run an older Node. Make the supported version your default (for example fnm default 24), then restart the client.

PowerShell says “running scripts is disabled on this system”. Run once: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned, then retry npx.

Ghidra queries time out in the agent. The first Ghidra query imports and auto-analyzes the binary, which can take minutes. REA allows 330,000 ms by default (REA_GHIDRA_STARTUP_TIMEOUT_MS), but your MCP client’s per-call timeout can be shorter.

Still stuck? Update first, retry, then open an issue with your REA version, target type, steps and error output. Once REA works, a native binary with the free Ghidra engine is a good next target: REA + Ghidra for native binaries.