How to Use REA with Claude Code and Codex: Inspect, Rebuild, and Verify

A coding agent can write a plausible version of a feature from a screenshot or a description. Reverse engineering asks a more precise question: what does the existing program actually do? REA gives an agent access to analysis tools so it can follow the evidence before writing a replacement.

REA — Reverse Engineer Anything is the repository currently featured in sAIgnals' trending repository view. This guide starts with a small Electron application, follows one export operation, and checks its CSV behavior. You can then apply the same workflow to software you maintain, a migration, a compatibility layer, or an older application you are authorized to inspect.

We checked the published npm version, 6.4.0, on 12 October 2026. We ran its static JavaScript analysis on the project's six-file Notes example and checked the formatter separately with Node.js. We did not test a live Claude Code or Codex MCP connection, native decompilation, or a complete application port. Commands for those integrations below follow the project's documentation.

What REA adds to your agent

There are three parts to the workflow. REA reads artifacts and returns structured findings. Your coding agent chooses follow-up questions, interprets those findings, and writes code. You define the behavior to preserve and check whether the reconstruction matches it.

Through MCP, the agent can call REA as a tool. The CLI exposes analysis workflows directly from a terminal. For native programs, REA can connect to analysis providers such as Ghidra, Hopper, or IDA. For packaged JavaScript and Electron applications, static inspection can work with the application directory or ASAR archive without a native provider. See the CLI guide for the distinction.

Start with one observable feature: an export, a parser, a clipboard operation, or a numeric calculation. A focused question gives you a result you can compare. “Rebuild this entire application” leaves too many behaviors undefined for a useful first investigation.

1. Check the runtime and select your client

The installation guide supports Node.js 22.x from 22.19, 24.x from 24.11, and 26 or later. Node 23 and 25 are unsupported. Check your environment and the currently published package:

node --version
npm --version
npm view rea-agents dist-tags.latest

The examples here pin 6.4.0 so that a future release does not silently change the setup. If you choose a newer version, check its release notes and use the same version for registration and analysis.

For Claude Code, inspect the setup plan:

npx rea-agents@6.4.0 setup --client claude_code --dry-run --json

For Codex, use:

npx rea-agents@6.4.0 setup --client codex --dry-run --json

Read the configuration and skill destinations in that plan. Then run the same command without --dry-run --json, approve the proposed changes in its interactive setup, and restart your agent. For example:

npx rea-agents@6.4.0 setup --client codex
npx rea-agents@6.4.0 doctor --client codex --json

Substitute claude_code for the Claude Code path. Setup registers the MCP server and matching workflow instructions. Installing only the skill from skills.sh supplies instructions; it does not register the analysis server. doctor checks registration and prerequisites, so also ask the restarted agent to list or call its REA tools. A valid configuration file alone does not prove that the current session loaded the server.

2. Use the supplied Notes example

The project's first-investigation guide provides a small Notes application. Download its example ZIP and extract it into a new working folder. The same six files are available in the repository's Notes example directory : package.json, index.html, renderer.js, preload.js, main.js, and csv.js.

Give the agent the absolute path to the extracted folder and a bounded question:

Use REA to inspect this Notes example statically. Trace what happens when
Export notes is clicked. Identify the renderer entry, preload API, IPC
channel, handler and CSV formatter. Read the relevant source ranges to
confirm the output destination and columns. Cite files and lines, and
separate recovered relationships from runtime assumptions. Do not launch
the app or change any files.

You do not need to install or launch Electron for this first step. For a direct terminal analysis:

npx -y rea-agents@6.4.0 analyze-javascript-application \
  /absolute/path/to/notes-example --json > notes-evidence.json

Replace the path with your extracted directory; quote paths that contain spaces. On Windows, use an absolute Windows path and your shell's line-continuation syntax, or put the command on one line.

Our static run recovered the source references and the notes:export relationship. The analysis output is a map for investigation; reading main.js establishes the actual destination expression. Keep the saved evidence alongside your notes instead of treating every inferred edge as proof of execution.

3. Follow the path from button to file

The supplied source gives this chain:

Those are facts from the example source . The Downloads location is read from app.getPath('downloads'); its resolved filesystem path depends on the machine. Static inspection does not establish that a click succeeds, that the folder is writable, or that a filesystem error is presented clearly to the user.

Ask one useful follow-up:

Follow the export failure path. If writeFileSync throws, where does the
error go? Identify what the renderer handles and what it leaves unhandled.
Show the source that supports the answer. Keep proposed improvements
separate from the behavior currently implemented.

That prevents the agent from quietly substituting a nicer imagined design for the implementation you are investigating.

4. Check a prediction with a small input

Before asking for a replacement, make a prediction you can test. For the note title Hello, "REA", the formatter should keep the comma inside one field and double the quotation marks:

id,title
1,"Hello, ""REA"""

From the example directory, this Bash/Zsh command checks the formatter without starting Electron:

node <<'JS'
const assert = require('node:assert/strict');
const { toCsv } = require('./csv.js');
const actual = toCsv([{ id: 1, title: 'Hello, "REA"' }]);
assert.equal(actual, 'id,title\n1,"Hello, ""REA"""\n');
process.stdout.write(actual);
JS

We ran this check successfully. It verifies the formatter for that input. It does not verify the button, IPC registration, file permissions, or the application's complete export workflow. Add representative inputs for your use case, such as an empty list, an empty title, a newline, and Unicode text. An end-to-end check requires running the application and inspecting its produced file separately.

5. Turn the finding into a specification and implementation

Now ask the agent for a compact behavioral specification before it edits your project:

Write a specification for this CSV export from the source and evidence.
Include column order, quoting, embedded quotation marks, newline behavior,
empty input and known failure behavior. Mark unresolved details. Then
propose how to implement the same observable behavior in my project.

Use that specification to request a narrow implementation:

Implement only the CSV formatter in this repository's language. Add tests
for the observed cases, compare outputs with the original formatter, and
show any differences. Keep the UI and file-writing behavior outside this
change. Do not copy unrelated application code or assets.

For a compatibility project, keep both implementations runnable against the same input set. Compare exact bytes when a downstream parser depends on them; compare an agreed semantic representation when harmless formatting differences are acceptable. Define that choice before declaring the result equivalent.

Our Notes exercise deliberately has readable source. It teaches the investigation and verification loop. A packaged app, obfuscated bundle, or stripped binary makes recovering the same specification harder and introduces more uncertainty.

6. Extend the method to binaries and existing products

Native analysis needs a provider and its prerequisites. Choose a supported Ghidra, Hopper, or IDA setup from the installation documentation , configure the relevant paths, and check the selected provider:

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

Ghidra needs its installation and a suitable JDK. Hopper and IDA have their own installation, platform and license requirements. Select the provider supported on your host rather than assuming the JavaScript workflow proves native readiness.

A strong worked example is DX-Ball's reconstruction repository . Its documented workflow uses Codex and REA to examine the original executable, implement readable C/C++, and compare behavior with original-x86 tests and compiled-byte checks. The sound-pan case study reports 3,205 checked cases and a 63-byte match for one helper. That is a result for a bounded function, not proof of complete game parity.

For an Electron feature, the Notion clipboard study shows a larger investigation through renderer, preload and IPC boundaries. It is useful when you need to understand how a rich-data operation crosses processes rather than merely reproduce the visible button.

Keep evidence and uncertainty in the final handoff

Ask the agent to deliver the target version or digest, the question investigated, source locations or instruction addresses, the reconstructed rule, tests and their actual outputs, and remaining unknowns. REA's artifact-analysis guide documents static-analysis limits: dynamic behavior, unresolved paths and inferred relationships require follow-up.

Keep the initial run static when that answers the question. Runtime inspection launches or interacts with a target and needs a deliberate test environment. REA performs analysis locally, while tool results passed to a hosted coding agent follow that provider's data policy. Choose permitted targets and reference data before starting an investigation; the project's MIT license covers its own code, not every app or asset you inspect.

Your first useful result can be small: one export traced, one rule recovered, and one test that confirms it. Repeat that loop as the specification grows. This is how REA becomes a practical development tool rather than a source of convincing but unverified reconstructions.