[GH-ISSUE #3016] Persist provider settings (GHIDRA_INSTALL_DIR, HOPPER_LAUNCHER_PATH, REA_JADX_MCP_JAR) in a REA config so the value survives client restarts #1055

Open
opened 2026-10-15 18:30:42 +00:00 by bsakaguchi · 2 comments
Owner

Originally created by @Selene0623 on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3016

Problem

Every provider setting is environment-variable-only. Scanning the rea-agents bundle (npm i -g rea-agents, 6.4.0) turns up GHIDRA_INSTALL_DIR, HOPPER_LAUNCHER_PATH, REA_IDA_MCP_CONFIG, REA_JADX_MCP_JAR, REA_GHIDRA_NATIVEAOT_JAR, REA_ILSPY_CMD_PATH, GHIDRA_STARTUP_TIMEOUT_MS, … with no config-file counterpart. There is also a single rea.json string in the bundle and no rea config command, so nothing owns the value.

That makes the setting fragile in three ways:

  1. It must be exported in the process that launches the MCP client. My Ghidra install is fully working (/opt/ghidra, ghidra 12.1.2-2.1; GHIDRA_INSTALL_DIR=/opt/ghidra rea doctor --json reports configured=true, available=true, providerVersion=12.1.2, "compatible 12.1.x release (verified build 12.1.4)", headless + native decompiler + JDK 27 all green). But an MCP client started by a desktop session — not by an interactive shell carrying the export — sees not_configured / "GHIDRA_INSTALL_DIR is not set", and the fix is to relaunch the whole client from a shell that exports it. The value is stable for years; the export is not.
  2. rea doctor, rea setup and the registered server each read the environment independently, so they can disagree. That is the same seam as #1183 (a relative GHIDRA_INSTALL_DIR passes doctor/setup and is rejected by the registered server at startup) and #1184 (configuration errors omit the rejected setting and its absolute-path constraint).
  3. There is no user-owned place to keep the choice. rea setup rewrites the client registrations (cf. #2944 for a value that does not survive into them, and #1606 for setup deleting configured settings), so a hand-edited env or registration is not durable.

Proposal

A persisted user config, e.g. ${XDG_CONFIG_HOME:-~/.config}/rea/config.json:

{
  "providers": {
    "ghidra": { "installDir": "/opt/ghidra" },
    "hopper": { "launcherPath": "…" },
    "jadx":   { "mcpJar": "…" }
  }
}

with

  • precedence env > config file > auto-detect, and the same resolution used by rea doctor, rea setup and the MCP server;
  • rea setup --ghidra /opt/ghidra (and friends) writing it, so the value is set once and survives client re-registration;
  • rea doctor printing the effective value and its source (env / config / auto), which would also make #1183/#1184 self-diagnosing;
  • no change for users who prefer env vars — they simply keep winning.

My case

Ghidra: installed at /opt/ghidra (Arch, ghidra 12.1.2-2.1); adb 1.0.41 also present. With the config above I would set it once and never touch a shell profile again.

Related: #2944, #1606, #1183, #1184, #1650.

Originally created by @Selene0623 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3016 ## Problem Every provider setting is environment-variable-only. Scanning the `rea-agents` bundle (`npm i -g rea-agents`, 6.4.0) turns up `GHIDRA_INSTALL_DIR`, `HOPPER_LAUNCHER_PATH`, `REA_IDA_MCP_CONFIG`, `REA_JADX_MCP_JAR`, `REA_GHIDRA_NATIVEAOT_JAR`, `REA_ILSPY_CMD_PATH`, `GHIDRA_STARTUP_TIMEOUT_MS`, … with no config-file counterpart. There is also a single `rea.json` string in the bundle and no `rea config` command, so nothing owns the value. That makes the setting fragile in three ways: 1. **It must be exported in the process that launches the MCP client.** My Ghidra install is fully working (`/opt/ghidra`, `ghidra 12.1.2-2.1`; `GHIDRA_INSTALL_DIR=/opt/ghidra rea doctor --json` reports `configured=true, available=true, providerVersion=12.1.2`, "compatible 12.1.x release (verified build 12.1.4)", headless + native decompiler + JDK 27 all green). But an MCP client started by a desktop session — not by an interactive shell carrying the export — sees `not_configured` / "GHIDRA_INSTALL_DIR is not set", and the fix is to relaunch the whole client from a shell that exports it. The value is stable for years; the export is not. 2. **`rea doctor`, `rea setup` and the registered server each read the environment independently**, so they can disagree. That is the same seam as #1183 (a relative `GHIDRA_INSTALL_DIR` passes doctor/setup and is rejected by the registered server at startup) and #1184 (configuration errors omit the rejected setting and its absolute-path constraint). 3. **There is no user-owned place to keep the choice.** `rea setup` rewrites the client registrations (cf. #2944 for a value that does not survive into them, and #1606 for setup deleting configured settings), so a hand-edited env or registration is not durable. ## Proposal A persisted user config, e.g. `${XDG_CONFIG_HOME:-~/.config}/rea/config.json`: ```json { "providers": { "ghidra": { "installDir": "/opt/ghidra" }, "hopper": { "launcherPath": "…" }, "jadx": { "mcpJar": "…" } } } ``` with - **precedence** env > config file > auto-detect, and the same resolution used by `rea doctor`, `rea setup` and the MCP server; - `rea setup --ghidra /opt/ghidra` (and friends) writing it, so the value is set once and survives client re-registration; - `rea doctor` printing the effective value **and its source** (`env` / `config` / `auto`), which would also make #1183/#1184 self-diagnosing; - no change for users who prefer env vars — they simply keep winning. ## My case Ghidra: installed at `/opt/ghidra` (Arch, `ghidra 12.1.2-2.1`); `adb` 1.0.41 also present. With the config above I would set it once and never touch a shell profile again. Related: #2944, #1606, #1183, #1184, #1650.
Author
Owner

@Jackzigen commented on GitHub (Oct 13, 2026):

Happy to take this one. Plan:

  1. New user-owned config at ${XDG_CONFIG_HOME:-~/.config}/rea/rea.json, validated by the same zod schema that owns the env vars (env > config > auto-detect precedence, merged once at the environment snapshot seam so doctor, setup, the registered MCP server and direct analysis all resolve identically — that also closes the #1183/#1184 disagreement seam).
  2. rea setup --ghidra <dir> (and --ida-config, --jadx-jar, --hopper-launcher, --ilspy-cmd) writing the values into that file.
  3. rea doctor reporting the effective value and its source (env / config / auto).
  4. Env vars keep winning, so current users see no change.

Scope note: starting with the provider settings named in this issue (GHIDRA_INSTALL_DIR, HOPPER_LAUNCHER_PATH, REA_JADX_MCP_JAR + the IDA/ILSpy paths) rather than every env var in the bundle — keeps the config surface small and reviewable. Draft PR soon.

<!-- gh-comment-id:6155530913 --> @Jackzigen commented on GitHub (Oct 13, 2026): Happy to take this one. Plan: 1. New user-owned config at `${XDG_CONFIG_HOME:-~/.config}/rea/rea.json`, validated by the same zod schema that owns the env vars (`env > config > auto-detect` precedence, merged once at the environment snapshot seam so `doctor`, `setup`, the registered MCP server and direct analysis all resolve identically — that also closes the #1183/#1184 disagreement seam). 2. `rea setup --ghidra <dir>` (and `--ida-config`, `--jadx-jar`, `--hopper-launcher`, `--ilspy-cmd`) writing the values into that file. 3. `rea doctor` reporting the effective value **and its source** (`env` / `config` / `auto`). 4. Env vars keep winning, so current users see no change. Scope note: starting with the provider settings named in this issue (`GHIDRA_INSTALL_DIR`, `HOPPER_LAUNCHER_PATH`, `REA_JADX_MCP_JAR` + the IDA/ILSpy paths) rather than every env var in the bundle — keeps the config surface small and reviewable. Draft PR soon.
Author
Owner

@Jackzigen commented on GitHub (Oct 13, 2026):

Opened #3023 with the fix: a ~/.config/rea/rea.json user config file merged into the environment snapshot (env > file > auto-detect) on both entry points, plus a rea config command to list/get/set values. test:fast green (427 files / 5560 tests).

<!-- gh-comment-id:6156112232 --> @Jackzigen commented on GitHub (Oct 13, 2026): Opened #3023 with the fix: a `~/.config/rea/rea.json` user config file merged into the environment snapshot (env > file > auto-detect) on both entry points, plus a `rea config` command to list/get/set values. `test:fast` green (427 files / 5560 tests).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#1055
No description provided.