REA puts Hopper and Ghidra behind an MCP server, then wires itself into your agents

The published tarball stopped seven weeks before main

package.json sits at version 3.1.0, and the newest release tag for the same version is rea-agents 3.1.0 dated 2026-08-09. The last push to main was 2026-09-30. Nothing about that gap is hidden, but it decides what you actually get when you follow the documentation, because the recommended invocation pins a tag rather than tracking the branch:

npx --yes rea-agents@latest setup

`@latest` resolves through npm to whatever release is published under that tag, which is 3.1.0 as of the tags above. Roughly seven weeks of work on main sit outside the tarball. The three most recent releases were 2.7.0 on 2026-07-28, 3.0.0 on 2026-08-02 and 3.1.0 on 2026-08-09, so a major bump and a minor bump landed inside two weeks and then the tag stream went quiet for seven. Read that as two different rhythms: fast iteration while a series is active, and an unknown window before the next publish.

The project is explicit about not papering over it. The documentation states that `@latest` makes the requested release explicit and asks npm for the release currently published under that tag, and that REA does not silently replace the package version npm selected, which keeps intentional rollbacks available through an exact package request. That is the behavior you want from a tool that edits agent configuration files, but it puts the pinning decision on you.

Versioning and release notes come from tooling rather than hand editing. The repository root carries .release-please-manifest.json and release-please-config.json, and CHANGELOG.md sits beside them, so the 3.0.0 step and the 2.7.0 to 3.1.0 run were generated from commit history rather than typed by a person.

Setup registers with six agents and deliberately leaves the seventh alone

Run setup once and it installs an aligned MCP registration plus the bundled routing skill. It detects Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf and Devin. Six of those get configured when found. Devin is detected and reported, then left untouched, on the stated ground that it has no documented local MCP configuration boundary. That is a narrower claim than unsupported: the wizard knows where to write for the other six because that surface is documented, and it declines where it is not.

The write path is described in terms that are worth checking against your own machine before you let it run. Registrations are additive rather than replacing whatever is already there, backup-first so a copy precedes the write, and read back afterwards to confirm what landed. Rerunning setup is safe by that account. Before anything changes, existing configuration is validated, exact paths and external effects are printed, and the final approval defaults to No. Ctrl-C or a decline leaves the system unchanged.

Four flags shape the run:

rea setup --dry-run

`--dry-run` shows the plan without applying it. Repeating `--client` selects exact agents instead of accepting the detected set. `--accessible` switches to sequential vertical prompts. `--json` keeps machine-readable output on stdout while prompt UI and progress go to stderr, which is the shape a scripted caller needs, and the split is worth knowing before you pipe it somewhere.

After a successful run the wizard reports which capabilities are ready and a concrete next step, such as restarting a configured agent before asking it to investigate an application. It states that it does not claim an integration or provider is ready unless setup and its final diagnostic check verified it, so a green summary is meant to mean something specific rather than that the script ran to the end.

The installer declines to install the Node version the manifest requires

Setup does not update Homebrew, Node.js, or npm. Set that beside the engines field in package.json, which is `^22.19.0 || >=24.11.0`, with packageManager pinned to [email protected]. The installer will not fetch the runtime its own manifest demands, so an older Node on your machine is a stop you discover at launch rather than something the wizard repairs. Anything on Node 20 is outside the range.

Three entry points reach the same CLI. A global install plus setup:

npm install --global rea-agents && rea setup

A package-runner invocation that downloads on demand:

npx rea-agents setup

And a curl wrapper that installs the same package and starts setup only when a terminal is available:

curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash

The wrapper takes its options after `bash -s --`, with `--dry-run`, `--no-setup` and `--version` given as examples. It reads install.sh from main rather than from the tag, so this one path is not version-pinned the way the npm paths are. The npm package runner prompt, when it appears, approves downloading REA for that invocation only; the wizard separately prints its plan and asks again before applying anything, so the two prompts are not one approval.

What you get from npm is an allowlist, not the repository. The files array publishes dist, install.sh, scripts/rea.mjs, four named scripts and hooks, two bridge files, skills, README.md and LICENSE. src, tests, docs, scripts as a directory and the repository tooling do not ship. Both bin names, `rea` and `rea-agents`, point at the single entry script scripts/rea.mjs, so the two command names are aliases rather than separate binaries. If you want to read how the package is built, clone it; node_modules will not tell you.

Hopper arrives through a Python bridge, Ghidra through one you install

Deep native analysis and function dossiers come through Hopper, or through a Ghidra you bring yourself on Linux. Both routes ship as single named files in the published package: bridge/hopper_bridge.py for Hopper, and bridge/ghidra/ReaGhidraBridge.java for Ghidra. One is Python, the other Java, which reflects where each host tool already lives rather than any preference in this codebase.

The Hopper path also carries scripts/hopper-demo-x11.py in the published file list. X11 in the filename points at an X11 session, which lines up with the Hopper desktop application on Linux. That is the shape of the macOS and Linux workstation route: you already own Hopper, REA talks to it through the bridge, and a small demo script exercises the path.

The Ghidra route is the one described as bring-your-own. No installer for Ghidra appears anywhere in the setup flow, and the wizard does not update Homebrew, which is where a Ghidra install usually lands on macOS. Nothing in the documentation describes fetching, pinning or validating a Ghidra distribution, so matching the version your REA bridge expects is on you, and the version REA 3.1.0 was tested against is not stated.

That asymmetry is the practical difference between the two providers. Hopper arrives as something REA drives over a bridge to a running desktop tool. Ghidra is a tool REA expects to find, already installed, already the right version, on Linux. Choose Hopper if you are on a workstation and already licensed for it; choose Ghidra if you are on Linux and want the analysis headless.

Windows native analysis is a gated P0, not a default path

Native PE work on Windows x64 is described as an experimental Windows x64 Ghidra P0, and the qualifier is specific: it is for approved native PE applications. That is a narrower boundary than platform support. A Ghidra P0 gates what you may analyze, so the set of Windows binaries you can hand to REA is smaller than the set you own, and the criteria for approval are not documented. There is also execution-free managed PE and CLI triage, which reads binaries without running them, and that sits in the same experimental region rather than in the settled Linux path.

The consequence for planning is simple. If Windows x64 native analysis is something you do every day, this is where an adoption conversation stops. You would be depending on an experimental path, scoped to approved applications, for a task that cannot be narrowed. If instead you mostly work on Linux, or you want managed PE triage without executing the sample, the wording does not obstruct you, because those cases sit outside the dependency.

One boundary holds across every platform and mode. REA does not claim to recover original source code or automatically clone an application. The stated output is readable code, strings, names and other clues about how a thing works, plus function dossiers. Anyone budgeting for this should plan on reimplementation rather than recovery, which is exactly what the Recreate step in the project's own model implies.

Passive observation, and an Electron hook that ships with its boundaries

Beyond native binaries the scope widens to controlled process capture, passive observation of websites, Electron pages and the Node and Electron V8 Inspector, JavaScript and source-map reconstruction, and provider-neutral graphs for connecting application layers. The word doing work in that list is passive. Runtime observation here is something REA watches, not something it injects into.

The published file list complicates that. Two Electron scripts ship together: scripts/electron-active-hook.cjs and scripts/electron-active-hook-boundaries.cjs. A hook described as active exists in the package, and a second file whose whole name is its boundaries ships right beside it. What that second file contains is not described anywhere in the readable documentation, so the honest reading is that the package carries the limits of its own hook as a first-class artifact without telling you what those limits are. If you rely on Electron instrumentation, that file is the thing to go read in the repository before you trust the output.

The evidence model is the other half. Results are recorded as reproducible Evidence records, and the graph layer is described as provider-neutral and built so that static inference is not confused with runtime observation. That is a claim about provenance: a conclusion drawn from a disassembly and a conclusion drawn from a live inspector session are kept distinguishable rather than merged into one answer. The value of that depends entirely on whether the records actually carry that distinction, which you can only judge from records REA produces for you.

Evidence records as the unit of work, and a tool catalog the English page never reaches

The project splits investigation into Decompile, Understand and Recreate. Open an app and recover readable code, strings and names. Follow the code from one part to another until the feature can be explained. Turn what was learned into a feature for your own product. Only the first step is a tool operation. The third is ordinary engineering that REA does not perform for you, which lines up with its refusal to claim it recovers source or clones an application. What REA is selling is the second step made repeatable, with commands, skills, structured results and an Evidence record per finding.

The English README is where this description thins out. Its own navigation bar promises six sections: Quick start, Current status, The investigation model, Tool catalog for investigation, Roadmap, and How it works. The Quick start section is the one that breaks off, cut mid-sentence on the line introducing installer options after `bash -s --`. Everything after it is absent from the readable English text. Current status, the tool catalog, the roadmap and How it works are all sections you would want before adopting this, and none of them are there to read. Four translations are listed at the top of the page, and README_zh.md, README_ja.md, README_ko.md and README_ar.md all exist in the repository, so the gap is specific to the copy in front of you rather than to the project.

The tool catalog matters more than the rest of the missing text, because it is the section that would say which providers exist on which platform, which is precisely the question this project cannot answer for you from its own documentation. Until it is published, treat the provider support described in the intro as the whole of what is documented, and check the repository directly before planning around Windows.

Editorial conclusion

Adopt it if you already keep Hopper or a Ghidra install and you want an agent to drive them, and accept that you are pinning a tarball that trails main by weeks. Skip it if Windows x64 native analysis is a daily requirement, because that route is an experimental P0 gated to approved applications, or if you need recovered source, which REA explicitly does not claim to produce. Before anything else, run `rea setup --dry-run` and read the paths it prints.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. morluto/rea on GitHub
4. README
5. Releases