2.2

rea doctor and the Ghidra provider

rea doctor runs nine checks for the Ghidra scope, and the provider is available only when the install directory, version, analyzeHeadless, native decompiler, and JDK 21 all pass.

You installed rea with npm and Ghidra with Homebrew, and your first rea function ended with provider_unavailable. The message tells you to run rea doctor. The report has nine checks for the Ghidra scope, each with a name, an ok flag, and the path or version it found. The first check that fails names the fix.

When you finish this section, you can read a doctor report, name the check that failed, and repair the install from its remediation text.

What the Ghidra provider needs

Ghidra provider: the rea adapter that drives an existing Ghidra install through analyzeHeadless. It needs two absolute paths from the environment, GHIDRA_INSTALL_DIR and JAVA_HOME, and it rejects relative ones. The policy fixes the versions: SUPPORTED_GHIDRA_VERSION = "12.1.4" and SUPPORTED_GHIDRA_JAVA_MAJOR = 21. In practice, the provider accepts Ghidra 12.1.x with a 64-bit full JDK inside the range that the install declares in application.java.min and application.java.max. The install must also hold the native decompiler for the host, under Ghidra/Features/Decompiler/os/<platform>/. REA does not build or install native tools, and it does not change the Gatekeeper quarantine settings.

On the capture Mac, Homebrew put both tools in place:

the Ghidra and JDK paths on the capture MactextFull log
…
GHIDRA_INSTALL_DIR=/opt/homebrew/Cellar/ghidra/12.1.4/libexec
application.build.date=2026-Sep-21 2017 GMT
application.version=12.1.4
application.release.name=PUBLIC

JAVA_HOME=/opt/homebrew/opt/openjdk@21
$ /opt/homebrew/opt/openjdk@21/bin/java -version
openjdk version "21.0.12.1" 2026-08-18
OpenJDK Runtime Environment Homebrew (build 21.0.12.1)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.12.1, mixed mode, sharing)
[exit 0]
…
Cut to the Ghidra and Java blocks. The rea, node, clang, llvm-objdump, macOS, and WABT blocks are cut.

The install docs give the same steps for any host: extract Ghidra, install the JDK outside REA, and export the two absolute paths. On a Mac with Homebrew, that is:

export GHIDRA_INSTALL_DIR=/opt/homebrew/Cellar/ghidra/12.1.4/libexec
export JAVA_HOME=/opt/homebrew/opt/openjdk@21
rea doctor --provider ghidra --format json

--provider ghidra narrows the report to one scope. Without it, the report also covers the Hopper, IDA, JADX, and Kuna providers, the installed skill, and the agent registrations on the machine.

The nine checks

the doctor report for the Ghidra scopejsonFull log
{
  "healthy": true,
  "environment_healthy": false,
  "scope": {
    "mode": "explicit",
    "clients": [],
    "providers": [
      "ghidra"
    ],
    "skill": false,
    "target": null
  },
  "scope_checks": [
    {
      "name": "node",
      "ok": true,
      "classification": "healthy",
      "detail": "22.22.0",
      "details": {
        "runtime": "node",
        "version": "22.22.0"
      }
    },
    …
    {
      "name": "ghidra-native_decompiler",
      "ok": true,
      "classification": "healthy",
      "detail": "/opt/homebrew/Cellar/ghidra/12.1.4/libexec/Ghidra/Features/Decompiler/os/mac_arm_64/decompile reports mach-o arm64, which matches darwin/arm64"
    },
    {
      "name": "ghidra-java",
      "ok": true,
      "classification": "healthy",
      "detail": "21.0.12.1; 64-bit; JDK; /opt/homebrew/Cellar/openjdk@21/21.0.12.1/libexec/openjdk.jdk/Contents/Home; accepted a 64-bit full JDK 21 or newer"
    }
  ]
}
Cut to the head, the first check, and the two checks that read the install. The other six checks are cut.

inspectGhidraInstallation runs the eight Ghidra checks without importing anything. Their order is configuration, platform, architecture, installation, version, headless, native_decompiler, and java, and the doctor prefixes each name with ghidra-. A node check comes first. The table names what each one reads and the code it returns when it fails.

CheckWhat it readsOn the capture MacFailure code
nodethe Node version22.22.0missing_dependency
ghidraGHIDRA_INSTALL_DIR, set and absolute/opt/homebrew/Cellar/ghidra/12.1.4/libexecnot_configured
ghidra-platformthe host OSdarwinunsupported_host
ghidra-architecturethe host CPUarm64unsupported_host
ghidra-installationGhidra/application.properties under the installthe properties fileexecutable_missing
ghidra-versionapplication.version against 12.1.x12.1.4unsupported_version or version_unresolved
ghidra-headlesssupport/analyzeHeadless, or .bat on Windowssupport/analyzeHeadlessexecutable_missing
ghidra-native_decompilerGhidra/Features/Decompiler/os/mac_arm_64/decompile and its executable headermach-o arm64, which matches darwin/arm64executable_missing
ghidra-javathe JDK, its major version against application.java.min, 64-bit, javac present21.0.12.1, 64-bit, JDKone code for each failed property

The native decompiler check reads the executable header of the decompile binary and compares it with the host. A build for another platform is therefore reported as incompatible, even when its directory name looks right. The doctor checks the platform, the architecture, and the Ghidra 12.1.x version. It also checks support/analyzeHeadless or support/analyzeHeadless.bat, the Java major range of the install, a 64-bit JDK, and javac or javac.exe. Figure 2.2 draws the nine in order.

Fig. 2.2the nine checks of rea doctor for the Ghidra scopeflow
The nine checks of rea doctor for the Ghidra scope Nine boxes in three rows, read left to right then down, each with the detail the capture Mac returned: node 22.22.0, ghidra with GHIDRA_INSTALL_DIR at ghidra/12.1.4/libexec, ghidra-platform darwin, ghidra-architecture arm64, ghidra-installation application.properties, ghidra-version 12.1.4 against the policy 12.1.x with JDK 21, ghidra-headless support/analyzeHeadless, ghidra-native_decompiler os/mac_arm_64/decompile which reports mach-o arm64 and matches, and ghidra-java 21.0.12.1 as a 64-bit JDK. Arrows connect the checks in order. Two result boxes at the bottom read healthy true for the explicit scope with providers ghidra and exit 0, and environment_healthy false for the audit-wide set that the capture filtered out. REA DOCTOR --PROVIDER GHIDRA · IN ORDER node 22.22.0 ok true, healthy ghidra GHIDRA_INSTALL_DIR ghidra/12.1.4/libexec ghidra-platform darwin ok true, healthy ghidra-architecture arm64 ok true, healthy ghidra-installation application.properties ok true, healthy ghidra-version 12.1.4 policy: 12.1.x, JDK 21 ghidra-headless support/analyzeHeadless ok true, healthy ghidra-native_decompiler os/mac_arm_64/decompile mach-o arm64 matches ghidra-java 21.0.12.1, 64-bit JDK ok true, healthy healthy: true scope explicit, providers [ghidra] exit 0, under one second environment_healthy: false the audit-wide set, outside this scope filtered out of the capture
rea doctor runs nine checks for the Ghidra scope in a fixed order, and on the capture Mac every one passed with the path or version it found. Read left to right, then down, and the two boxes at the bottom are the report's two verdicts.

healthy and environment_healthy

The report has two verdicts. healthy is the verdict for the selected scope, here explicit with providers: ["ghidra"], and scope_checks lists only the checks in that scope. environment_healthy is the verdict for the audit-wide set. It is true only when every check outside the providers passes, every configured provider passes, and at least one provider is available.

On the capture Mac healthy is true and environment_healthy is false. Hopper, IDA, and Kuna are not configured there, so the formula ignores them, and Ghidra is configured and passes. The false verdict therefore comes from a check outside the Ghidra scope. That check is in the set the capture's --filter-output left out, which names this user's skill install and agent registrations (the capture). The exit status follows the scope. rea doctor returned 0 (the capture), because a missing optional provider only produces a note for tasks that do not use it.

When a check fails

The capture kit did not record a failing doctor, because Ghidra was installed. The source says what you would see. With GHIDRA_INSTALL_DIR unset, the configuration check fails with the detail GHIDRA_INSTALL_DIR is not set and the remediation Set GHIDRA_INSTALL_DIR to an extracted Ghidra 12.1.x release directory.. With a relative path, the detail is GHIDRA_INSTALL_DIR must be absolute.

A rea function --provider ghidra on such a machine fails selection with the code provider_unavailable, the category unavailable, and retryable: true. The message is The selected analysis provider is unavailable. Review the reported local diagnostics or run rea doctor, then retry.. Its details.rejections[].diagnostics.checks[] holds the same eight checks as the doctor. Section 2.3 shows those diagnostics inside rea capabilities, and the errors reference lists the codes.

One check has no fix in rea. Every Ghidra record on macOS carries the limitation that "macOS sessions require a matching executable Ghidra native decompiler; REA checks for it but does not build native components or change Gatekeeper quarantine state." (the capture). If the Homebrew build of decompile is missing or quarantined, you repair Ghidra, not rea.

rea (rea-agents) with the Ghidra provider rea-agents 6.7.0, Ghidra 12.1.4 · 27dc42d · 2026-10-18 · Edition 2026.10