REA Turns Coding Agents Into Reverse Engineers. "Local" Doesn't Mean the Evidence Stays Put.

The top repo on today's trending board runs its analysis locally. What it finds goes wherever your agent sends its conversation, and that's the part to plan for.

"Runs locally" has become the most reassuring phrase in agent tooling. It shows up on MCP servers, browser tools and code indexers, and it usually means something narrower than readers assume.

It means the tool runs on your laptop. It doesn't mean the results stay there.

That gap matters most for a tool like REA, short for "Reverse Engineer Anything," which was #1 on Trendshift's fast-moving daily board when I read it at about 3:15 PM ET on October 18, 2026. REA hands an AI agent the ability to open compiled programs, Electron apps, .NET assemblies and websites and explain how they work. Its README says "REA analyzes targets locally." Its own FAQ then adds the sentence that should shape how you use it: "Your agent receives the tool results, and its model provider has its own data policy."

Both statements are true. Put together, they mean the decompiling happens on your machine and the findings travel with your agent's conversation to whoever runs the model. If you point REA at your own app, that's fine. If you point it at a client's binary under NDA, you just sent a description of its internals to a third party.

Here's what REA does, where its findings actually go, and a short routine to run before you aim it at anything sensitive.

What REA is, in plain terms

Reverse engineering means working out how a program behaves from the program itself, usually the compiled file, without the original source code. Traditionally it takes specialist tools and a lot of patience. A disassembler turns machine code back into readable instructions, a decompiler tries to rebuild something close to source code, and a human spends days tracing which function calls which.

REA wraps that work behind MCP (the Model Context Protocol, the standard plug that lets coding agents call outside tools). Once it's installed, an agent like Claude Code or Codex can ask REA to inspect a target, trace a piece of behavior, and get back findings "with the evidence and limitations behind each conclusion," in the README's words.

The range of targets is wide: native binaries (with Hopper, Ghidra or IDA installed), JavaScript and Electron apps, .NET assemblies, Android apps, firmware, network captures and live websites, among others. The README's support table lists what each one needs.

The project's showcase is a good picture of how much detail comes back. REA traced a sound call in the old game DX-Ball into its helper functions, and the resulting reconstruction "passes 3,205 original-x86 cases and reproduces all 63 compiled function bytes," per the README. That's the maintainer's own case study, not an independent benchmark, but it shows the level: function-by-function behavior, down to the bytes.

REA is MIT-licensed, and release rea-agents-6.7.0 shipped today, October 18. Star counts for the repo disagree wildly across sources right now, so treat any number you see as unreliable.

Where a finding actually goes

Follow one finding from start to finish. It helps to picture REA as a very capable research assistant who works in your office but reports to someone else's inbox.

1. Your agent asks. You tell Claude Code, "explain how this app checks its license key." The agent calls an REA tool over MCP.
2. REA works locally. It runs the decompiler or the JavaScript analysis on your machine and builds a result: the functions it found, the strings, the call paths, its conclusion and its evidence.
3. The result enters the conversation. MCP tool results come back to the agent as part of the chat. That's how tool calling works; the model can only reason about what's in its context.
4. The conversation goes to the model. The agent sends the conversation, including that result, to its model provider so the model can decide what to do next. Anthropic's Claude Code data usage page says the data it sends "includes all user prompts and model outputs."
5. The provider's policy takes over. Retention and training rules now apply to your finding just as they apply to any prompt.

For Claude Code specifically, the same page lays out what step 5 means. Commercial accounts (Team, Enterprise and API) get a standard 30-day retention period, and Anthropic says it does not train on Claude Code data under commercial terms unless the customer opts into a program that shares data for model improvement. Consumer plans (Free, Pro and Max) keep data for 30 days if you've turned off model-improvement use, or 5 years if you've allowed it. Zero data retention exists, but only for qualified Claude for Enterprise accounts, enabled per organization.

There's a sixth stop people forget. Claude Code also keeps session transcripts on your own disk, "in plaintext under ~/.claude/projects/ for 30 days by default," per the same page. So the decompiled internals of whatever you analyzed sit in a readable file in your home directory for a month, alongside everything else in that session.

None of this is a flaw in REA. It's how every MCP tool works. REA just makes the stakes unusually concrete, because the thing traveling isn't a weather forecast. It's how somebody's software works inside.

Put this into practice

The goal is simple: know what your agent will receive, and choose where it goes, before the first real target.

Step 1: install and review the setup. REA needs Node.js 22.19 or later on the 22 line, 24.11 or later on 24, or 26 and up, plus npm.

npx rea-agents@6.7.0 setup

Setup asks you to "choose your agents, review the proposed changes, and approve them." It registers the MCP server and workflow instructions with the agents you pick (the README lists Claude Code, Codex, Cursor, Gemini CLI and others) and backs up your existing configuration first. Read the proposed config changes rather than clicking through. Then restart your agent.

Step 2: run one analysis without an agent and read the output. REA's CLI can run the same kind of analysis directly, with no model involved:

npx -y rea-agents@6.7.0 analyze-javascript-application /absolute/path/to/your/app --json > rea-findings.json

Pick an Electron or JavaScript app you own. Open rea-findings.json and read it. This is the step most people skip, and it's the most useful ten minutes in this article. Static JavaScript inspection "read[s] the supplied files without running the application," so the target app never launches (REA and Node still run, of course). On Linux, this needs a procps-compatible ps on your PATH. What you're looking at is the kind of evidence an agent would get back and pass along. If anything in that file would worry you on someone else's server, you now know before it happens.

Step 3: sort your targets into three buckets.

• Your own software. Your code, your binary, your call. The standard provider path is usually fine.
• Software you're allowed to inspect but don't own. Open-source dependencies, apps you're licensed to audit. Check the license and your provider's terms.
• Anything under contract. A client's binary, firmware under NDA, internal tools from an employer. Don't send these through a consumer plan. Use a commercial account whose retention terms your contract allows, or keep the model local.

Step 4: for the sensitive bucket, keep the model off the network. A local gateway such as magpie, which sat further down the same trending board, lets you point coding agents at local model servers instead of a cloud provider. The gateway only keeps things local if the model behind it is local; route it to a cloud API and the findings travel again. A local model will be weaker at long reverse-engineering chains, so expect slower, rougher answers. That's the trade for keeping findings on your hardware. The other option is to skip the agent entirely for those targets and use REA's CLI output yourself.

Step 5: shrink the local copy. If you analyze sensitive targets in Claude Code, lower cleanupPeriodDays in ~/.claude/settings.json (for example "cleanupPeriodDays": 7) so transcripts don't sit in ~/.claude/projects/ for the default 30 days, and delete the session when you're done. The docs note that sessions started or last continued in Claude Desktop or Cowork are exempt from that cleanup by default, so run sensitive analysis from the terminal.

Step 6: isolate runtime capture. Static inspection reads files; runtime capture watches the program while it actually runs, and some REA workflows do that. The README says runtime capture "runs or interacts with the selected target using your user permissions." Running an unknown program with your permissions is exactly as risky as double-clicking it. Do that work in a virtual machine or a throwaway user account.

Honest limitations

REA documents no redaction. As far as the README goes, it describes no setting that strips strings, keys or identifiers from results before your agent sees them. If a hardcoded API key turns up in a target, assume it can end up in the conversation.

Deep native work needs outside tools, and some cost money. Native binaries need Hopper, Ghidra or IDA installed. Commercial tools like IDA Pro, Hopper or JEB carry their own licenses that REA doesn't grant. Ghidra is the free route.

Legal use is on you. The README says REA "is for lawful research, education, interoperability, software preservation," and points to a separate DISCLAIMER file. Many software licenses forbid reverse engineering, and an agent that can explain any binary in minutes doesn't change what your license says.

The project moves fast. Two releases landed today, and the 6.7.0 notes say 6.6.0 was tagged but never published to npm. Pin a version for real work, as the Step 2 command does, so a surprise update doesn't change behavior mid-investigation.

Popularity numbers are noisy. Star figures for the repo conflict across sources this week. Judge it by running it on your own app, not by the badge.

This article is about data flow, not quality. I read the README, the release notes and Claude Code's data policy. I haven't benchmarked REA's findings against a human reverse engineer, and the DX-Ball case study is the maintainer's own.

The question to ask every "local" tool

REA is a sharp, honest tool. It tells you where its results go, in its own FAQ, which is more than most MCP servers manage.

The habit worth building is bigger than REA. Every time a tool says "local," ask two questions. Where does the work run? And where does the answer go? For any MCP server, the second answer is "wherever your agent sends its conversation." Run the CLI, read the JSON, pick your provider path, then let the agent loose.

Sources: morluto/rea README and FAQ (reviewed at rea-agents-6.7.0, October 18, 2026); rea releases; Claude Code data usage; yetone/magpie; Trendshift daily board (read about 15:15 ET, October 18, 2026).