morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #1183] [Bug] Doctor and setup accept a relative `GHIDRA_INSTALL_DIR` that the registered MCP server rejects at startup #417

New issue

Closed

opened 2026-10-15 18:24:53 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:24:53 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1183

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

With a relative GHIDRA_INSTALL_DIR that resolves to the expected Ghidra layout, scoped doctor reports a healthy and available provider. Setup copies that relative path into the MCP registration and reports ready, but the registered server exits before initialization because REA's configuration parser requires an absolute installation path. The same environment also makes providers and capabilities fail. Unscoped doctor's Ghidra inspection has the same false positive, even when unrelated checks make its overall health false.

Both tested builds returned exit 0 and healthy: true from scoped doctor. Its Ghidra inspection contained available: true, no failed checks, and registrationEnvironment.GHIDRA_INSTALL_DIR: "./fixture". Unscoped doctor also reported Ghidra available with every Ghidra check passing.

Both providers and capabilities returned exit 1 with error.code: "configuration_invalid". Their message was REA configuration is invalid. Run \rea doctor` and fix the reported setting.`

Both setup dry-runs returned exit 0 and status: "planned", with GHIDRA_INSTALL_DIR=./fixture in the registration action. Both isolated apply runs returned exit 0 and status: "ready". The config readback included:

[mcp_servers.rea.env]
GHIDRA_INSTALL_DIR = "./fixture"

Launching each stored registration returned exit 1, empty stdout, and REA configuration is invalid. Run \rea doctor` and fix the reported setting.on stderr. The absolute-path controls passed doctor and discovery in both builds. Applying the absolute fixture root to the same isolated registration restored MCP initialization in both builds: each stored command answered a stdioinitializerequest and exited 0 after stdin closed, with empty stderr. A separate relativeJAVA_HOME` symlink to the valid JDK also passed scoped doctor while discovery rejected its absolute-path constraint; setup's observed Java-home normalization makes the installation-path case the demonstrated registration failure.

Reproduction

Use the runtime baseline below and an existing supported installation. Create the fixture and the client trial home outside any repository. The following fixture contains only a copied properties file and symlinks to the existing launcher and native decompiler; it never changes the installation.

ghidra_root=/path/to/ghidra_12.1.4_PUBLIC
jdk_root=/path/to/jdk-21
node_bin="$(dirname "$(node -p process.execPath)")"
work_dir="$(mktemp -d /tmp/agent-work.XXXXXX)"
trial_home="$work_dir/home"
mkdir -p "$trial_home" "$work_dir/fixture/support" "$work_dir/fixture/Ghidra/Features/Decompiler/build/os/mac_arm_64"
cp "$ghidra_root/Ghidra/application.properties" "$work_dir/fixture/Ghidra/application.properties"
ln -s "$ghidra_root/support/analyzeHeadless" "$work_dir/fixture/support/analyzeHeadless"
ln -s "$ghidra_root/Ghidra/Features/Decompiler/build/os/mac_arm_64/decompile" "$work_dir/fixture/Ghidra/Features/Decompiler/build/os/mac_arm_64/decompile"
cd "$work_dir"
rea_trial() {
  env -u CLAUDE_CONFIG_DIR -u CODEX_HOME -u COPILOT_HOME -u OPENCODE_CONFIG -u XDG_CONFIG_HOME \
    HOME="$trial_home" PATH="$node_bin:$PATH" \
    GHIDRA_INSTALL_DIR=./fixture JAVA_HOME="$jdk_root" \
    npx -y rea-agents@6.1.0 "$@"
}
rea_trial doctor --provider ghidra --json
rea_trial doctor --json
rea_trial providers --json
rea_trial capabilities --json
rea_trial setup --client codex --skill=false --dry-run --json
rea_trial setup --client codex --skill=false --yes --json
cat "$trial_home/.codex/config.toml"
rea_trial mcp

The --yes command above must run only with the isolated HOME and cleared client overrides shown here. Both dry-run and apply were executed in the trial home. The registered command and its stored environment were also launched with empty stdin, which reproduced the startup failure. Repeat the REA calls using node /path/to/rea/scripts/rea.mjs instead of the package runner to exercise the main build. As a control, use the absolute fixture path or the absolute real installation path; doctor and discovery then agree, and setup's plan contains an absolute installation path.

Expected behavior

The installation guide requires absolute Ghidra and Java paths and says setup preserves valid detected settings in registrations. Doctor and setup must use an admission rule compatible with the runtime parser. For the relative installation value, they should either diagnose the absolute-path constraint or resolve and publish a valid absolute registration value. A successful setup result must not install an environment that the registered REA server immediately rejects.

Impact and scope

A bounded configuration input receives a successful setup result but installs a registration that cannot start, and doctor supplies a false healthy result for the same input. Impact assessment: P2 (supported).

Workaround (available): Replacing the installation value with its absolute path passed doctor and discovery, produced an absolute setup plan, and restored initialization of the same isolated MCP registration in both tested builds.

REA version

rea-agents@6.1.0 from npm, and main at b34bdcdb28 built locally with npm ci && npm run build:cached.

Runtime and platform

The tested release was rea-agents 6.1.0. The prepared main build was commit b34bdcdb2877be394c59c9cbf70269dc1841ff78, directly verified with git rev-parse HEAD. The installation was the official Ghidra 12.1.4 distribution with locally built macOS arm64 natives. Java was the 64-bit full Homebrew OpenJDK 21.0.12.1, Node was 24.21.0, and the host was macOS 27.0.1 arm64. All setup changes and registration launches used an isolated HOME with the client-directory override variables cleared.

Target and artifact context

Not target-specific (Ghidra provider admission and client registration)

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Expected source: docs/installation.md:460 requires absolute paths; docs/installation.md:482 says setup preserves valid detected Ghidra/JDK settings in agent registrations (the sentence sits in the Windows setup paragraph), and docs/installation.md:486–:491 describes doctor's Ghidra validation and the exact environment entries setup records on every platform; src/config/environment.ts:18 enforces the absolute GHIDRA_INSTALL_DIR constraint.
Failure source: The executed doctor, discovery, setup plan, isolated setup apply, config readback, and registration startup commands above. src/ghidra/GhidraDoctor.ts:60 bypasses the configuration parser; src/ghidra/GhidraInstallation.ts:309 treats every non-null installation value as configured; src/ghidra/GhidraDoctor.ts:29 publishes that value unchanged into the registration environment.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Verification covered both builds, stored registration startup, and the absolute-path controls. Source locators explain the observed admission mismatch.

Typed outcome or recovery expected

Repeat the same relative-root fixture through scoped and unscoped doctor, both discovery aliases, and isolated setup dry-run/apply. The passing result must either reject the relative value with its exact constraint before registering it, or consistently resolve it to a valid absolute value and allow the stored MCP registration to start. Preserve the healthy absolute-path controls and Java-home discovery through PATH. Merely changing the final error text or suppressing the startup error does not restore the registration contract.

Analysis or suspected cause

No response

Additional context

No response

Originally created by @coygeek on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1183 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior With a relative `GHIDRA_INSTALL_DIR` that resolves to the expected Ghidra layout, scoped doctor reports a healthy and available provider. Setup copies that relative path into the MCP registration and reports `ready`, but the registered server exits before initialization because REA's configuration parser requires an absolute installation path. The same environment also makes `providers` and `capabilities` fail. Unscoped doctor's Ghidra inspection has the same false positive, even when unrelated checks make its overall health false. Both tested builds returned exit 0 and `healthy: true` from scoped doctor. Its Ghidra inspection contained `available: true`, no failed checks, and `registrationEnvironment.GHIDRA_INSTALL_DIR: "./fixture"`. Unscoped doctor also reported Ghidra available with every Ghidra check passing. Both `providers` and `capabilities` returned exit 1 with `error.code: "configuration_invalid"`. Their message was `REA configuration is invalid. Run \`rea doctor\` and fix the reported setting.` Both setup dry-runs returned exit 0 and `status: "planned"`, with `GHIDRA_INSTALL_DIR=./fixture` in the registration action. Both isolated apply runs returned exit 0 and `status: "ready"`. The config readback included: ```toml [mcp_servers.rea.env] GHIDRA_INSTALL_DIR = "./fixture" ``` Launching each stored registration returned exit 1, empty stdout, and `REA configuration is invalid. Run \`rea doctor\` and fix the reported setting.` on stderr. The absolute-path controls passed doctor and discovery in both builds. Applying the absolute fixture root to the same isolated registration restored MCP initialization in both builds: each stored command answered a stdio `initialize` request and exited 0 after stdin closed, with empty stderr. A separate relative `JAVA_HOME` symlink to the valid JDK also passed scoped doctor while discovery rejected its absolute-path constraint; setup's observed Java-home normalization makes the installation-path case the demonstrated registration failure. ### Reproduction Use the runtime baseline below and an existing supported installation. Create the fixture and the client trial home outside any repository. The following fixture contains only a copied properties file and symlinks to the existing launcher and native decompiler; it never changes the installation. ```sh ghidra_root=/path/to/ghidra_12.1.4_PUBLIC jdk_root=/path/to/jdk-21 node_bin="$(dirname "$(node -p process.execPath)")" work_dir="$(mktemp -d /tmp/agent-work.XXXXXX)" trial_home="$work_dir/home" mkdir -p "$trial_home" "$work_dir/fixture/support" "$work_dir/fixture/Ghidra/Features/Decompiler/build/os/mac_arm_64" cp "$ghidra_root/Ghidra/application.properties" "$work_dir/fixture/Ghidra/application.properties" ln -s "$ghidra_root/support/analyzeHeadless" "$work_dir/fixture/support/analyzeHeadless" ln -s "$ghidra_root/Ghidra/Features/Decompiler/build/os/mac_arm_64/decompile" "$work_dir/fixture/Ghidra/Features/Decompiler/build/os/mac_arm_64/decompile" cd "$work_dir" rea_trial() { env -u CLAUDE_CONFIG_DIR -u CODEX_HOME -u COPILOT_HOME -u OPENCODE_CONFIG -u XDG_CONFIG_HOME \ HOME="$trial_home" PATH="$node_bin:$PATH" \ GHIDRA_INSTALL_DIR=./fixture JAVA_HOME="$jdk_root" \ npx -y rea-agents@6.1.0 "$@" } rea_trial doctor --provider ghidra --json rea_trial doctor --json rea_trial providers --json rea_trial capabilities --json rea_trial setup --client codex --skill=false --dry-run --json rea_trial setup --client codex --skill=false --yes --json cat "$trial_home/.codex/config.toml" rea_trial mcp ``` The `--yes` command above must run only with the isolated HOME and cleared client overrides shown here. Both dry-run and apply were executed in the trial home. The registered command and its stored environment were also launched with empty stdin, which reproduced the startup failure. Repeat the REA calls using `node /path/to/rea/scripts/rea.mjs` instead of the package runner to exercise the main build. As a control, use the absolute fixture path or the absolute real installation path; doctor and discovery then agree, and setup's plan contains an absolute installation path. ### Expected behavior The installation guide requires absolute Ghidra and Java paths and says setup preserves valid detected settings in registrations. Doctor and setup must use an admission rule compatible with the runtime parser. For the relative installation value, they should either diagnose the absolute-path constraint or resolve and publish a valid absolute registration value. A successful setup result must not install an environment that the registered REA server immediately rejects. ### Impact and scope A bounded configuration input receives a successful setup result but installs a registration that cannot start, and doctor supplies a false healthy result for the same input. Impact assessment: P2 (supported). Workaround (available): Replacing the installation value with its absolute path passed doctor and discovery, produced an absolute setup plan, and restored initialization of the same isolated MCP registration in both tested builds. ### REA version `rea-agents@6.1.0` from npm, and `main` at b34bdcdb2877be394c59c9cbf70269dc1841ff78 built locally with `npm ci && npm run build:cached`. ### Runtime and platform The tested release was `rea-agents` 6.1.0. The prepared main build was commit `b34bdcdb2877be394c59c9cbf70269dc1841ff78`, directly verified with `git rev-parse HEAD`. The installation was the official Ghidra 12.1.4 distribution with locally built macOS arm64 natives. Java was the 64-bit full Homebrew OpenJDK 21.0.12.1, Node was 24.21.0, and the host was macOS 27.0.1 arm64. All setup changes and registration launches used an isolated HOME with the client-directory override variables cleared. ### Target and artifact context Not target-specific (Ghidra provider admission and client registration) ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence - Expected source: `docs/installation.md:460` requires absolute paths; `docs/installation.md:482` says setup preserves valid detected Ghidra/JDK settings in agent registrations (the sentence sits in the Windows setup paragraph), and `docs/installation.md:486`–`:491` describes doctor's Ghidra validation and the exact environment entries setup records on every platform; `src/config/environment.ts:18` enforces the absolute `GHIDRA_INSTALL_DIR` constraint. - Failure source: The executed doctor, discovery, setup plan, isolated setup apply, config readback, and registration startup commands above. `src/ghidra/GhidraDoctor.ts:60` bypasses the configuration parser; `src/ghidra/GhidraInstallation.ts:309` treats every non-null installation value as configured; `src/ghidra/GhidraDoctor.ts:29` publishes that value unchanged into the registration environment. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Verification covered both builds, stored registration startup, and the absolute-path controls. Source locators explain the observed admission mismatch. ### Typed outcome or recovery expected Repeat the same relative-root fixture through scoped and unscoped doctor, both discovery aliases, and isolated setup dry-run/apply. The passing result must either reject the relative value with its exact constraint before registering it, or consistently resolve it to a valid absolute value and allow the stored MCP registration to start. Preserve the healthy absolute-path controls and Java-home discovery through PATH. Merely changing the final error text or suppressing the startup error does not restore the registration contract. ### Analysis or suspected cause _No response_ ### Additional context _No response_

bsakaguchi

2026-10-15 18:24:53 +00:00

closed this issue
added the
area: setup

bug
labels

bsakaguchi referenced this issue

2026-10-16 21:12:56 +00:00

[PR #417] [MERGED] build: shorten local validation loops #1967

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#417

No description provided.

Rows
Columns

[GH-ISSUE #1183] [Bug] Doctor and setup accept a relative GHIDRA_INSTALL_DIR that the registered MCP server rejects at startup #417