REA Guide (unofficial)What is REAInstallMCP SetupTroubleshooting & FAQREA vs Ghidra/IDAUse Cases

Fix REA Ghidra timeouts

Unofficial guide. This site is an independent community guide and is not affiliated with the REA project. For authoritative docs see the official REA website and the morluto/rea GitHub repository. Commands here are taken from the official README/docs (checked 2026-10-13); REA changes quickly, so verify against the official docs.

Why it times out

The first Ghidra-backed query triggers import and auto-analysis. The provider startup deadline defaults to 330,000 ms (5.5 min). Big binaries need longer.

Fix 1: raise the startup deadline

export REA_GHIDRA_STARTUP_TIMEOUT_MS=1800000   # any integer 1–2147483647 ms

Set it in the environment of the REA MCP server (the env of the rea entry in your agent config), not just a random terminal. Empty or invalid values fail config validation. Hopper has REA_HOPPER_STARTUP_TIMEOUT_MS.

Fix 2: the agent's own tool-call timeout

The docs warn this deadline is separate from your MCP client's per-call deadline — "a client can time out earlier even when Ghidra would complete." Issue #1720 reports query tools failing at ~60 s with MCP error -32001: Request timed out even with a large REA_GHIDRA_STARTUP_TIMEOUT_MS. Raise your client's MCP request timeout too, and prefer opening the target and running a first query via the CLI to warm up if needed.

Fix 3: auto-analysis stalls in one analyzer

For Swift/Objective-C arm64 Mach-O targets, analysis can stall in the Objective-C message analyzer (#1783). Skip it:

export REA_GHIDRA_DISABLED_ANALYZERS="Objective-C Message Analyzer"

Names must match exact Ghidra analyzer names (comma-separated). Disabling an analyzer skips the facts it would produce.

Fix 4: memory

Give the JVM more heap with GHIDRA_HEADLESS_MAXMEM (default 2G).

Related guides

Sources: installation.md · issue #1720 · issue #1783

FAQ

What is REA's default Ghidra startup timeout?

330,000 ms. Raise it with REA_GHIDRA_STARTUP_TIMEOUT_MS in the server environment.

Why does my agent still time out after ~60 seconds?

The MCP client's own request deadline is separate; see issue #1720.