[GH-ISSUE #1184] [Bug] Configuration errors omit the rejected Ghidra setting and its absolute-path constraint #418

Closed
opened 2026-10-15 18:24:54 +00:00 by bsakaguchi · 0 comments
Owner

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

Before submitting

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

Area

Provider or capability discovery

Observed behavior

REA rejects relative Ghidra environment paths with configuration_invalid, but its CLI error and MCP startup message omit the variable name and the absolute-path requirement. The only advice is to run doctor, which can report Ghidra healthy for the same environment. This prevents the error from telling callers which setting to correct. The failure is independently reproducible with valid absolute Ghidra and Java paths and only a relative optional NativeAOT JAR path.

For all three relative environment-path cases, both tested builds returned exit 1 from discovery with the following complete error object. Neither details nor any other field named the setting or its constraint:

{
  "error": {
    "code": "configuration_invalid",
    "category": "execution_failure",
    "message": "REA configuration is invalid. Run `rea doctor` and fix the reported setting.",
    "retryable": false,
    "remediation": {
      "action": "REA configuration is invalid. Run `rea doctor` and fix the reported setting."
    }
  }
}

The relative-JAR case returned exit 0 and healthy: true from scoped doctor in both builds. The relative installation and relative JDK cases also passed scoped doctor when their paths resolved to the positive fixture. A stored registration using the relative installation value exited 1 before MCP initialization and printed the same generic message to stderr. Removing the optional JAR variable restored the discovery result without changing Ghidra or Java.

Reproduction

Use the runtime baseline below and the working Ghidra/JDK environment. Run each case independently, keeping the other environment paths valid and absolute:

export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC
export JAVA_HOME=/path/to/jdk-21
REA_GHIDRA_NATIVEAOT_JAR=./missing.jar npx -y rea-agents@6.1.0 providers --json
REA_GHIDRA_NATIVEAOT_JAR=./missing.jar npx -y rea-agents@6.1.0 capabilities --json
REA_GHIDRA_NATIVEAOT_JAR=./missing.jar npx -y rea-agents@6.1.0 doctor --provider ghidra --json

Repeat using node /path/to/rea/scripts/rea.mjs in place of the package runner. The JAR file need not exist because environment validation rejects the relative path before any artifact check. Additional executed cases used GHIDRA_INSTALL_DIR=./fixture and JAVA_HOME=./jdk, with the relative paths resolving to a valid minimal Ghidra tree and a symlink to the actual JDK. Each produced the same error without a setting name or constraint. As a control, omit the optional JAR variable; discovery succeeds and reports Ghidra available with the unchanged absolute installation and JDK paths.

Expected behavior

The repository's Boundary Contracts require diagnostics to identify the failed constraint and require recovery advice to address that reason. The parser already identifies REA_GHIDRA_NATIVEAOT_JAR must be absolute, and it has equivalent checks for the Ghidra installation and Java-home variables. The public error should preserve the rejected field and its applicable constraint. Any suggested doctor route must actually diagnose that failure, or the error must give the correction directly.

Impact and scope

Users with a rejected environment setting cannot identify the failed field from the error, and the suggested diagnostic command can report the provider healthy. Impact assessment: P2 (supported).

Workaround (available): Inspect the documented environment-path requirements and use absolute paths, or omit the unneeded optional JAR variable; the latter discovery control passed 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 release was rea-agents 6.1.0 and the prepared main build was commit b34bdcdb2877be394c59c9cbf70269dc1841ff78. The healthy control used official Ghidra 12.1.4 with locally built macOS arm64 natives, 64-bit full Homebrew OpenJDK 21.0.12.1, Node 24.21.0, and macOS 27.0.1 arm64. The supporting registration probe used an isolated HOME with all client-directory overrides cleared.

Target and artifact context

Not target-specific (environment configuration)

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

  • Expected source: AGENTS.md:61, Boundary Contracts, requires preservation of meaningful failure reasons and actionable validation details; src/config/environment.ts:18, :23, and :28 provide the three concrete absolute-path constraints.
  • Failure source: The executed CLI error objects and doctor controls above. src/config/environment.ts:55 retains the Zod validation error only as a cause; src/domain/analysisErrorPresentation.ts:191 replaces the message with generic doctor advice; src/domain/analysisErrorProjection.ts:44 produces the public projection without these field-specific configuration details.
  • Evidence provenance: observed
  • Local verification: reproduced
  • Reproduction completeness: complete

Verification covered both builds, including the optional-JAR case with valid absolute Ghidra and Java paths. The source explains the lost diagnostic information but is not the primary failure evidence.

Typed outcome or recovery expected

Run the REA_GHIDRA_NATIVEAOT_JAR=./missing.jar case, with valid absolute Ghidra and Java paths, through both discovery aliases. The error must identify the rejected variable and the absolute-path requirement in caller-visible output, and any suggested diagnostic route must report the same failure rather than a healthy provider. Apply the same check to the relative GHIDRA_INSTALL_DIR and JAVA_HOME cases, including MCP startup, for as long as REA rejects those values; if a separate fix makes REA resolve them to absolute paths instead, those two cases no longer produce this error and the optional-JAR case alone carries the check. The no-JAR absolute-path control must continue to succeed.

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/1184 ### 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 Provider or capability discovery ### Observed behavior REA rejects relative Ghidra environment paths with `configuration_invalid`, but its CLI error and MCP startup message omit the variable name and the absolute-path requirement. The only advice is to run doctor, which can report Ghidra healthy for the same environment. This prevents the error from telling callers which setting to correct. The failure is independently reproducible with valid absolute Ghidra and Java paths and only a relative optional NativeAOT JAR path. For all three relative environment-path cases, both tested builds returned exit 1 from discovery with the following complete error object. Neither `details` nor any other field named the setting or its constraint: ```json { "error": { "code": "configuration_invalid", "category": "execution_failure", "message": "REA configuration is invalid. Run `rea doctor` and fix the reported setting.", "retryable": false, "remediation": { "action": "REA configuration is invalid. Run `rea doctor` and fix the reported setting." } } } ``` The relative-JAR case returned exit 0 and `healthy: true` from scoped doctor in both builds. The relative installation and relative JDK cases also passed scoped doctor when their paths resolved to the positive fixture. A stored registration using the relative installation value exited 1 before MCP initialization and printed the same generic message to stderr. Removing the optional JAR variable restored the discovery result without changing Ghidra or Java. ### Reproduction Use the runtime baseline below and the working Ghidra/JDK environment. Run each case independently, keeping the other environment paths valid and absolute: ```sh export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC export JAVA_HOME=/path/to/jdk-21 REA_GHIDRA_NATIVEAOT_JAR=./missing.jar npx -y rea-agents@6.1.0 providers --json REA_GHIDRA_NATIVEAOT_JAR=./missing.jar npx -y rea-agents@6.1.0 capabilities --json REA_GHIDRA_NATIVEAOT_JAR=./missing.jar npx -y rea-agents@6.1.0 doctor --provider ghidra --json ``` Repeat using `node /path/to/rea/scripts/rea.mjs` in place of the package runner. The JAR file need not exist because environment validation rejects the relative path before any artifact check. Additional executed cases used `GHIDRA_INSTALL_DIR=./fixture` and `JAVA_HOME=./jdk`, with the relative paths resolving to a valid minimal Ghidra tree and a symlink to the actual JDK. Each produced the same error without a setting name or constraint. As a control, omit the optional JAR variable; discovery succeeds and reports Ghidra available with the unchanged absolute installation and JDK paths. ### Expected behavior The repository's Boundary Contracts require diagnostics to identify the failed constraint and require recovery advice to address that reason. The parser already identifies `REA_GHIDRA_NATIVEAOT_JAR must be absolute`, and it has equivalent checks for the Ghidra installation and Java-home variables. The public error should preserve the rejected field and its applicable constraint. Any suggested doctor route must actually diagnose that failure, or the error must give the correction directly. ### Impact and scope Users with a rejected environment setting cannot identify the failed field from the error, and the suggested diagnostic command can report the provider healthy. Impact assessment: P2 (supported). Workaround (available): Inspect the documented environment-path requirements and use absolute paths, or omit the unneeded optional JAR variable; the latter discovery control passed 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 release was `rea-agents` 6.1.0 and the prepared main build was commit `b34bdcdb2877be394c59c9cbf70269dc1841ff78`. The healthy control used official Ghidra 12.1.4 with locally built macOS arm64 natives, 64-bit full Homebrew OpenJDK 21.0.12.1, Node 24.21.0, and macOS 27.0.1 arm64. The supporting registration probe used an isolated HOME with all client-directory overrides cleared. ### Target and artifact context Not target-specific (environment configuration) ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence - Expected source: `AGENTS.md:61`, Boundary Contracts, requires preservation of meaningful failure reasons and actionable validation details; `src/config/environment.ts:18`, `:23`, and `:28` provide the three concrete absolute-path constraints. - Failure source: The executed CLI error objects and doctor controls above. `src/config/environment.ts:55` retains the Zod validation error only as a cause; `src/domain/analysisErrorPresentation.ts:191` replaces the message with generic doctor advice; `src/domain/analysisErrorProjection.ts:44` produces the public projection without these field-specific configuration details. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Verification covered both builds, including the optional-JAR case with valid absolute Ghidra and Java paths. The source explains the lost diagnostic information but is not the primary failure evidence. ### Typed outcome or recovery expected Run the `REA_GHIDRA_NATIVEAOT_JAR=./missing.jar` case, with valid absolute Ghidra and Java paths, through both discovery aliases. The error must identify the rejected variable and the absolute-path requirement in caller-visible output, and any suggested diagnostic route must report the same failure rather than a healthy provider. Apply the same check to the relative `GHIDRA_INSTALL_DIR` and `JAVA_HOME` cases, including MCP startup, for as long as REA rejects those values; if a separate fix makes REA resolve them to absolute paths instead, those two cases no longer produce this error and the optional-JAR case alone carries the check. The no-JAR absolute-path control must continue to succeed. ### Analysis or suspected cause _No response_ ### Additional context _No response_
bsakaguchi 2026-10-15 18:24:54 +00:00
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#418
No description provided.