morluto/rea

Fork 0

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

[GH-ISSUE #2944] [Bug] Setup does not carry REA_JADX_MCP_JAR into agent registrations #1036

New issue

Closed

opened 2026-10-15 18:30:33 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:30:33 +00:00

Owner

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

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 both GHIDRA_INSTALL_DIR and REA_JADX_MCP_JAR set in the shell, rea setup --client claude_code records only the Ghidra/JDK values in the planned MCP registration. REA_JADX_MCP_JAR is omitted, so the registered MCP server has a working JADX provider only if the agent client happens to inherit that variable from its own environment.

The same command run in that shell works with JADX, which is what makes the omission easy to miss: CLI checks pass, while an agent started without the variable gets capability_unavailable for the Android tools.

Reproduction

PowerShell, Windows 11 x64, REA 6.4.0 from npm (also reproduced with a source build of main at ebaaa79ca):

$env:GHIDRA_INSTALL_DIR = 'C:\tools\ghidra_12.1.4_PUBLIC'
$env:REA_JADX_MCP_JAR = 'C:\tools\jadx\jadx-headless-mcp-0.7.1-all.jar' (the audited 0.7.1 JAR, SHA-256 6e5eacf5…ff75)
rea setup --client claude_code --dry-run --json
Observe the configure_client:claude_code action detail: only GHIDRA_INSTALL_DIR and JAVA_HOME appear under "Detected provider environment".
For contrast, in the same shell rea search-android-classes MainActivity loads the APK through JADX 0.7.1; after removing REA_JADX_MCP_JAR from the process environment it returns capability_unavailable asking to set the variable.

Expected behavior

Setup records a valid detected REA_JADX_MCP_JAR (and the JDK it resolved) in the agent registration, the same way it records GHIDRA_INSTALL_DIR and JAVA_HOME, and lists it under "Detected provider environment" in the plan so the user can approve it.

If carrying it is intentionally out of scope, the docs could say that setup does not record it and that it must be added to the client's MCP server environment by hand.

Impact and scope

Affects the Android/JADX tools in agent sessions whose client process lacks REA_JADX_MCP_JAR (for example a GUI client launched before the variable was set, or with the variable set only in one shell).

CLI use in a shell that has the variable is not affected; Ghidra/IDA registration is not affected.

No evidence-integrity or isolation impact: the tools fail closed with capability_unavailable.

Workaround: add REA_JADX_MCP_JAR to the env of the client's REA server entry manually. Later rea setup runs retain it ("Existing server environment overrides are retained"); verified on 6.4.0.

REA version

6.4.0 (npm); also main ebaaa79ca built from source

Runtime and platform

Windows 11 x64; Node 22.23.2 (package) and 24.18.0 (source build); Temurin JDK 21.0.10; Ghidra 12.1.4; jadx-headless-mcp 0.7.1

Target and artifact context

Any APK (reproduced with Open Camera from F-Droid); not target-specific

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

setup --client claude_code --dry-run --json  (REA_JADX_MCP_JAR set in the process)
configure_client:claude_code: ... Detected provider environment: GHIDRA_INSTALL_DIR=C:\tools\ghidra_12.1.4_PUBLIC, JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-21.0.10.7-hotspot. Existing server environment overrides are retained; detected values replace matching keys.

doctor.providerInspections registrationEnvironment:
  ghidra -> {"GHIDRA_INSTALL_DIR": "...", "JAVA_HOME": "..."}
  ida    -> {}

search-android-classes without REA_JADX_MCP_JAR (6.4.0):
{"code":"capability_unavailable","category":"unsupported_provider","message":"Set REA_JADX_MCP_JAR to the absolute path of a caller-supplied jadx-headless-mcp 0.7.1 JAR. REA does not download or install it.", ...}

Typed outcome or recovery expected

The setup plan lists REA_JADX_MCP_JAR among the detected provider environment entries, and the applied registration contains it.

Analysis or suspected cause

Source-derived, not runtime-traced: providerRegistrationEnvironment in src/application/SetupRegistrationEnvironment.ts builds the registration environment only from DoctorProviderInspection.registrationEnvironment. On main, only GhidraDoctor and IdaDoctor publish one, and there is no provider inspection for JADX/Android, so its variable never reaches the registration.

docs/android-analysis.md says to "set the path in the shell or MCP server environment", so leaving it to the user may be intended. docs/installation.md gives the rationale for recording the JDK home ("so GUI MCP clients do not depend on an incidental shell path"), and that rationale applies equally to the JADX JAR.

Additional context

Happy to open a PR if the approach is agreed, for example a JADX provider inspection that validates the configured JAR (reusing the existing JADX configuration checks) and publishes REA_JADX_MCP_JAR as registration environment, with a setup-plan regression test alongside the existing Ghidra ones.

Originally created by @katrezving on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2944 ### 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 both GHIDRA_INSTALL_DIR and REA_JADX_MCP_JAR set in the shell, rea setup --client claude_code records only the Ghidra/JDK values in the planned MCP registration. REA_JADX_MCP_JAR is omitted, so the registered MCP server has a working JADX provider only if the agent client happens to inherit that variable from its own environment. The same command run in that shell works with JADX, which is what makes the omission easy to miss: CLI checks pass, while an agent started without the variable gets capability_unavailable for the Android tools. ### Reproduction PowerShell, Windows 11 x64, REA 6.4.0 from npm (also reproduced with a source build of main at ebaaa79ca): $env:GHIDRA_INSTALL_DIR = 'C:\tools\ghidra_12.1.4_PUBLIC' $env:REA_JADX_MCP_JAR = 'C:\tools\jadx\jadx-headless-mcp-0.7.1-all.jar' (the audited 0.7.1 JAR, SHA-256 6e5eacf5…ff75) rea setup --client claude_code --dry-run --json Observe the configure_client:claude_code action detail: only GHIDRA_INSTALL_DIR and JAVA_HOME appear under "Detected provider environment". For contrast, in the same shell rea search-android-classes <apk> MainActivity loads the APK through JADX 0.7.1; after removing REA_JADX_MCP_JAR from the process environment it returns capability_unavailable asking to set the variable. ### Expected behavior Setup records a valid detected REA_JADX_MCP_JAR (and the JDK it resolved) in the agent registration, the same way it records GHIDRA_INSTALL_DIR and JAVA_HOME, and lists it under "Detected provider environment" in the plan so the user can approve it. If carrying it is intentionally out of scope, the docs could say that setup does not record it and that it must be added to the client's MCP server environment by hand. ### Impact and scope Affects the Android/JADX tools in agent sessions whose client process lacks REA_JADX_MCP_JAR (for example a GUI client launched before the variable was set, or with the variable set only in one shell). CLI use in a shell that has the variable is not affected; Ghidra/IDA registration is not affected. No evidence-integrity or isolation impact: the tools fail closed with capability_unavailable. Workaround: add REA_JADX_MCP_JAR to the env of the client's REA server entry manually. Later rea setup runs retain it ("Existing server environment overrides are retained"); verified on 6.4.0. ### REA version 6.4.0 (npm); also main ebaaa79ca built from source ### Runtime and platform Windows 11 x64; Node 22.23.2 (package) and 24.18.0 (source build); Temurin JDK 21.0.10; Ghidra 12.1.4; jadx-headless-mcp 0.7.1 ### Target and artifact context Any APK (reproduced with Open Camera from F-Droid); not target-specific ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence ```text setup --client claude_code --dry-run --json (REA_JADX_MCP_JAR set in the process) configure_client:claude_code: ... Detected provider environment: GHIDRA_INSTALL_DIR=C:\tools\ghidra_12.1.4_PUBLIC, JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-21.0.10.7-hotspot. Existing server environment overrides are retained; detected values replace matching keys. doctor.providerInspections registrationEnvironment: ghidra -> {"GHIDRA_INSTALL_DIR": "...", "JAVA_HOME": "..."} ida -> {} search-android-classes without REA_JADX_MCP_JAR (6.4.0): {"code":"capability_unavailable","category":"unsupported_provider","message":"Set REA_JADX_MCP_JAR to the absolute path of a caller-supplied jadx-headless-mcp 0.7.1 JAR. REA does not download or install it.", ...} ``` ### Typed outcome or recovery expected The setup plan lists REA_JADX_MCP_JAR among the detected provider environment entries, and the applied registration contains it. ### Analysis or suspected cause Source-derived, not runtime-traced: providerRegistrationEnvironment in src/application/SetupRegistrationEnvironment.ts builds the registration environment only from DoctorProviderInspection.registrationEnvironment. On main, only GhidraDoctor and IdaDoctor publish one, and there is no provider inspection for JADX/Android, so its variable never reaches the registration. docs/android-analysis.md says to "set the path in the shell or MCP server environment", so leaving it to the user may be intended. docs/installation.md gives the rationale for recording the JDK home ("so GUI MCP clients do not depend on an incidental shell path"), and that rationale applies equally to the JADX JAR. ### Additional context Happy to open a PR if the approach is agreed, for example a JADX provider inspection that validates the configured JAR (reusing the existing JADX configuration checks) and publishes REA_JADX_MCP_JAR as registration environment, with a setup-plan regression test alongside the existing Ghidra ones.

bsakaguchi

2026-10-15 18:30:33 +00:00

closed this issue
added the
area: setup

triage

bug
labels

bsakaguchi commented

2026-10-15 18:30:34 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Addressed on main in ec56c1da0.

JADX doctor and setup registration preserve REA_JADX_MCP_JAR; closes environment omission at registration boundary.

Validation: Focused JADX/setup report plus global check, docs:check, Python and package verification pass.

Verification scope: No real JADX server launched; this closes the registration environment omission.

@morluto commented on GitHub (Oct 14, 2026): Addressed on main in [ec56c1da0](https://github.com/morluto/rea/commit/ec56c1da0). JADX doctor and setup registration preserve REA_JADX_MCP_JAR; closes environment omission at registration boundary. Validation: Focused JADX/setup report plus global check, docs:check, Python and package verification pass. Verification scope: No real JADX server launched; this closes the registration environment omission.

bsakaguchi referenced this issue

2026-10-16 21:06:23 +00:00

[GH-ISSUE #3892] [Bug] OpenStep keyed archives drop __proto__ entries without an omission limitation #1510

bsakaguchi referenced this issue

2026-10-17 21:07:36 +00:00

[PR #992] [MERGED] feat(browser): inspect historical web network captures #2561

bsakaguchi referenced this issue

2026-10-17 21:08:09 +00:00

[PR #1049] [MERGED] fix(domain): preserve prototype-named JSON members through Evidence boundaries #2607

bsakaguchi referenced this issue

2026-10-17 21:08:37 +00:00

[PR #1101] [CLOSED] fix: cross-platform correctness, MCP transport ceiling, and Windows boundary stabilization #2649