REA ("Reverse Engineer Anything", npm package rea-agents) is an MIT-licensed MCP server and CLI that hands coding agents reverse-engineering tools. Point Claude Code, Codex, Cursor, Gemini CLI, Grok Build or another agent at a binary, an Electron app, an APK or a website, and the agent can pull out strings, decompiled methods, routes and network observations. The repository has passed 100,000 stars (GitHub shows about 170,000 on October 13, 2026) and the latest npm release is 6.4.0.
That is a useful capability and a larger permission surface than most MCP servers add. This post looks at REA through the lens of someone who runs agents: what npx rea-agents setup changes in your config, what runtime capture can touch, and what to review and approve. Everything about REA below comes from its public README, SECURITY.md and AGENTS.md; explainx.ai has not audited REA's code, and nothing here is a claim about vulnerabilities in it.
TL;DR: REA's footprint on an agent setup
| Question | Answer, per REA's documentation |
|---|---|
| What does it do? | MCP server and CLI for inspecting binaries, Electron/JS, .NET, APKs, firmware, websites, HAR captures and process runs |
| What does setup change? | Adds REA's MCP server and workflow instructions to chosen agents, with backups of existing config |
| Is setup unattended? | No. You choose agents, review proposed changes and approve them |
| Does analysis run the target? | Static JS and .NET inspection does not. Runtime capture does, with your user permissions |
| Is it a sandbox? | No. SECURITY.md says it is "not a sandbox" |
| Does data leave my machine? | Analysis is local, but results go to your agent's model provider |
| Does it install software? | Optionally Hopper, after approval |
What does REA let an agent do?
REA's README lists targets by type, each with its own requirements. Native binaries need Hopper, Ghidra or IDA as the analysis provider. JavaScript and Electron inspection covers modules, imports, source maps, routes and IPC. Android work needs headless JADX and a JDK. Websites need a Chrome-family browser. Firmware uses Binwalk or Unblob on Linux. Process capture needs Linux or macOS.
The list has grown since our first read. It now also covers offline ELF layout, Go binaries, WASM artifacts, EVM bytecode, SQLite databases, recorded Linux crashes, Flutter apps, JEB projects, Android resources, logic-signal recordings and saved captures (HAR, Fiddler SAZ). Most of the newer targets use a tool you supply, such as pwntools, WABT, Apktool, TShark or sigrok-cli. The latest addition is bounded packet-capture summaries (endpoints, DNS, TLS SNI, HTTP requests) through tshark and capinfos, which the README marks as Linux-verified.
Two additions widen the footprint beyond reading files. Android device support covers devices, packages, processes, logs, dumps, screen captures and APK or file transfers through a caller-supplied adb, on an emulator or real hardware. JEB support talks to a JEB client you start yourself and point REA at with REA_JEB_MCP_URL. Treat a connected phone as live access to that device, not as a file on disk.
The common thread is that the agent no longer just reads your source. It reads other people's compiled artifacts, which are untrusted input by definition. Strings, symbols, decompiled output and web page content all come back as tool results, and tool results go into the model's context. That is the same prompt-injection surface covered in MCP security and indirect prompt injection, applied to a domain where the content is adversarial more often than usual.
What does npx rea-agents setup change?
Per the README, setup lets you choose agents, shows proposed changes, waits for your approval, and then adds "REA's MCP server and matching workflow instructions, with backups of existing configuration." You restart the agent afterward. REA's AGENTS.md separately states that rea setup must get approval before writing files, and SECURITY.md says setup "may update client configuration only after showing a plan and getting approval."
Two things get added, and both matter:
- An MCP server entry in each selected agent's config. From then on, every session of that agent can launch REA and call its tools.
- Workflow instructions or a skill. These are text the agent reads and follows. They shape how the agent approaches a target, so they deserve the same scrutiny as any
SKILL.md.
The README does not list the exact files it edits, so do not rely on a path from a blog post. Instead, snapshot your config before you run setup and diff it after.
# Before: copy the agent config you expect setup to touch (path varies by agent)
cp ~/.claude.json ~/rea-before-claude.json
npx rea-agents setup
# After: see exactly what changed
diff ~/rea-before-claude.json ~/.claude.json
REA changes quickly, so setup is not a one-time event. The README tells you to run rea update for a global install, or npx rea-agents@latest setup to refresh agent registrations, and to review the changes and restart the agent each time. Re-run your diff after every update.
If you let setup optionally install Hopper, that is a separate approval. SECURITY.md describes the Linux path as HTTPS-only metadata, a restricted download origin, a size cap and a SHA-1 check against a published checksum, and it notes SHA-1 is a corruption check rather than a signature. On macOS, the README says a first-run dialog may ask you to pick demo mode or activate a license.
What can runtime capture touch?
This is the line that matters most. The README states: "Runtime capture runs or interacts with the selected target using your user permissions." Static JavaScript and .NET inspection read supplied files and do not run the application. Runtime capture, process comparison and website inspection do interact with something live.
If the target is an unknown binary or an installer, running it as you means it can read your home directory, your SSH keys, your cloud credentials and your agent's own config. REA's SECURITY.md is direct about this: "This is not a sandbox and does not protect against malicious processes already running as the same operating-system user," and opening an untrusted binary "delegates parsing and analysis to the selected local provider with that user's permissions."
SECURITY.md does describe hardening for Ghidra sessions (an isolated temporary project, private directories, size limits, CPU and heap caps, cleanup on close) and a capability token with a current-user Unix socket for the local provider bridge. Those reduce accidental persistence and resource use. The same document says they do not make Ghidra a sandbox.
In practice, the safe habit is to run runtime capture on untrusted targets inside a disposable VM or container, not on the machine that holds your credentials. That is a recommendation from us, not a feature of REA.
What should you review before approving?
A short checklist, in the order it is cheapest to check:
- The proposed config diff. Confirm which agents are touched and what command the MCP entry launches. Prefer a pinned package version over an unpinned
npxcall, since an unpinned entry resolves to whatever is published at launch time. REA recommendsrea updateto stay current, so decide deliberately when to move versions. - The workflow instructions. Read them as you would a skill. Look for anything that tells the agent to skip confirmation or run commands without asking.
- Which agents get it. An agent with broad permissions and auto-approval deserves REA less than one that asks before running tools.
- Connected devices. If you enable ADB, decide which emulator or phone the agent may reach before it can pull logs, dumps or files from it.
- Runtime tools. Decide per session whether the agent may use capture on a target, and where.
- Where results go. Per REA's FAQ, results reach the agent's model provider. Do not feed it proprietary binaries or captures with customer data unless that provider's policy allows it.
Our MCP security guide walks through the same pre-connect review for any server, and the MCP primer and Claude Code MCP setup guide cover how the config entries work.
What to do before and after you run it
Before you run it. Snapshot and diff your agent config as shown above. Then read any skill or instruction file setup installed the way you would read a SKILL.md: line by line, looking for instructions to skip confirmation. Check whether the MCP entry pins a package version, since an unpinned npx entry resolves to whatever is published at launch time.
While it runs. Keep a record of what the agent actually launches. If your agent uses REA to start a process capture, the resulting shell and tool activity is the evidence you want afterward to answer "what did the agent actually run?" Most agent harnesses expose hooks or logs for this; see what an agent harness is. AgentBeam is an agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions, and is one option for the monitoring and blocking layer.
Where all of this stops. Be clear about the limits:
- No config scanner analyzes REA's code, and a clean scan is one input, not clearance. Pattern scanners catch known shapes, not novel ones.
- Agent-level monitoring sees what the agent asked for, not what a target process does once REA runs it.
- Hook-based enforcement is not a kernel sandbox, and it depends on the agent honoring its hooks.
- Nothing at the agent layer contains a malicious binary. A VM or container does that.
Authorization and licensing
REA's README and DISCLAIMER.md say it is for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine. It also says you must legally obtain commercial tools such as IDA Pro, Hopper and JEB yourself, and that REA grants no license, key or activation entitlement. If you plan to point an agent at someone else's app, check the target's terms and your jurisdiction first. That is a legal question this post does not answer.
Is an AI-assisted repo a concern?
REA's repository includes an AGENTS.md written largely for AI coding agents. It covers architecture rules, strict TypeScript, validation of external input, small composable MCP tools and Conventional Commits. It also notes that Turborepo writes a managed guidance block into the repo when it detects an agent. Having an AGENTS.md says the maintainers use agents in development. It tells you nothing about code quality either way, so judge REA the way you judge any dependency: pin it, read what it asks to change, and watch what it does.
Frequently asked questions
What is REA?
REA ("Reverse Engineer Anything") is an MIT-licensed MCP server and CLI, published on npm as rea-agents, that lets coding agents inspect native binaries, Electron and JavaScript apps, .NET assemblies, APKs, firmware, websites and saved network captures, and compare process runs. Its README describes it as letting an agent inspect a target, trace relevant code and return findings with evidence.
What does npx rea-agents setup change?
Per the README, setup adds REA's MCP server and matching workflow instructions to the agents you choose, with backups of existing configuration. You review and approve the proposed changes first, and restart the agent afterward. The README does not list exact file paths, so diff your agent config before and after.
Does REA run the program it analyzes?
Static inspection of JavaScript and .NET reads supplied files without running the application. Runtime capture is different: the README says it "runs or interacts with the selected target using your user permissions." Treat runtime capture as executing the target.
Does my data stay on my machine when I use REA?
Analysis runs locally, but your agent receives the tool results and its model provider has its own data policy, per REA's FAQ. Anything REA extracts from a target and returns to the agent can leave your machine through the agent's model provider.
Can a scanner tell me whether REA is safe?
No. A config scanner is a heuristic text check of an MCP config or skill file, and it does not run or audit REA's code. You can scan the config entry setup writes and record the tool calls your agent makes afterward, but a clean scan is not clearance.
Related reading
-
leanrea: an 8 KB skill that claims to replace the REA server
-
Related: Replica skill, eleven Claude skills that clone an app clean-room
Details about REA reflect its public README, SECURITY.md and AGENTS.md. SECURITY.md and AGENTS.md were last read on October 9, 2026; the README was re-read on October 13, 2026. Details may change between releases.
Update, October 9, 2026: New companion post on what REA's published case studies prove and where they stop: Reverse engineering is now a prompt.
Update, October 13, 2026: Refreshed the target list (now including ADB devices, JEB, WASM, EVM, SQLite, Flutter and packet summaries), star count and update guidance from the current README.