REA setup currently configures the capabilities that exist today: its bundled skill, detected agent integrations, optional Hopper provider, and validated bring-your-own Ghidra paths. It detects Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, and Devin. The first six have documented local MCP configuration boundaries and can be updated additively; Devin is reported but left unchanged.
The Ghidra foundation supports Linux x64 with exact Ghidra 12.1.2 and a 64-bit full JDK 21. An experimental Windows x64 P0 admits approved native x86-64 PE applications through the same 19-operation Java bridge. Doctor validates those coordinates; approved Linux/macOS setup propagates them to MCP registrations without installing or modifying either dependency. REA's packaged Java bridge then proves an isolated read-only headless import, post-analysis handshake, complete cleanup, ten admitted read-only inventory operations, and nine function-analysis operations. Real source-owned x86-64 debug/stripped ELF, AArch64 ELF, PE, and Mach-O fixtures cover program, procedure, string, symbol, external/thunk, memory, resolution, search, decompilation, assembly, calls, typed references, xrefs, and CFG semantics. Hosted Windows CI covers build, package, target admission, transport, and lifecycle seams; a controlled self-hosted workflow covers the real Ghidra P0 claim.
Extend formats or semantics only with normalized provider-neutral contracts and real source-owned conformance. Hopper and Ghidra pseudocode or assembly text is not expected to match; unresolved targetless flow remains unknown. Automatic Ghidra acquisition, if ever added, remains a separately planned and approved related-tool change; setup must never install Java.
Before Windows advances beyond P0, add current-user-only DACL creation and readback, handle-based reparse-point-safe path authority, a DACL-protected IPC backend, and Job Object assignment before provider execution. Process capture, controlled replay, Hopper, and broad filesystem-sensitive workflows remain separate Windows projects rather than implied parity.
After REA ships at least two real optional toolchains, setup can evolve into a capability-oriented wizard. It may ask whether the operator wants to investigate native binaries, websites, mobile applications, firmware, or runtime protocols, then propose only the tools needed for the selected work.
That future installer must preserve the current safety boundary:
- detect and reuse existing tools;
- disclose every source, destination, license, command, and system effect;
- prefer user-local installation;
- install only explicitly selected toolchains;
- require tool-specific authorization for unattended system changes;
- verify each installed tool before reporting readiness.
No placeholder tool choices or speculative installer registry are implemented until another supported toolchain makes the abstraction concrete.