morluto/rea

Fork 0

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

[GH-ISSUE #3068] [Bug] binary_session reports configured Apktool tools as provider_missing #1074

New issue

Closed

opened 2026-10-15 18:30:51 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

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

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

binary_session reports both Apktool tools as unavailable with reason: "provider_missing" and a generic remediation, even when REA_APKTOOL_COMMAND points at a working Apktool launcher. In the same MCP session, inspect_apktool_client succeeds. Agents that choose operations from tool_availability, as the MCP contract instructs, are told Android resource decoding cannot run while Apktool is configured. Android/JADX entries already follow their engine's readiness (fixed in #1124).

On 6.4.0, binary_session listed both apktool-provider tools (decode_android_resources, inspect_apktool_client) as available: false, reason: "provider_missing", remediation "Install or configure a provider that declares this operation.". inspect_apktool_client in the same server then succeeded and reported Apktool 3.0.3 with command_source: "environment".

The main build gave the same per-tool facts in grouped form: both apktool-provider groups had available: false, reason: "provider_missing", and the same generic remediation, and inspect_apktool_client again succeeded. The entries do not change with configuration: in runs on both builds with REA_APKTOOL_COMMAND unset (and apktool not on PATH), both Apktool entries were identical, while inspect_apktool_client then failed with capability_unavailable. An earlier run of 6.4.0 with Apktool 2.7.0, the version docs/apktool-resource-analysis.md names as verified, reported the same entries; that run was not repeated for this report. decode_android_resources was not run, because no APK was used.

Reproduction

Create an Apktool launcher (for example a shell script that runs java -jar apktool.jar "$@"), then start the server with it configured: REA_APKTOOL_COMMAND=/abs/apktool npx -y rea-agents@6.4.0 mcp. No APK or open target is needed. For the main build, start node scripts/rea.mjs mcp from the compiled checkout (npm ci --ignore-scripts, npm run compile) with the same environment instead.
From a stdio MCP client, send these newline-delimited messages in order, waiting for the initialize response before sending the rest.

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"availability-probe","version":"1.0.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"binary_session","arguments":{}}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"inspect_apktool_client","arguments":{}}}

In response 2, read result.structuredContent.result.tool_availability and select the entries whose surface is apktool-provider. On main, expand tool_availability.groups into per-tool entries first.
Compare those entries with response 3.

Expected behavior

docs/mcp-contracts.md (lines 114-119 at the 6.4.0 tag; lines 337-347 on main in grouped form) says: "Call binary_session with {} and read result.tool_availability to choose a callable operation for the current target, provider, host, and negotiated client capabilities", with each tool's availability, reason, and remediation. The Apktool tools need no open_binary target; decode_android_resources takes its APK as a path argument. With the launcher configured and callable, inspect_apktool_client and decode_android_resources should be reported available, as the android-provider tools are when the JADX JAR and JDK are ready. When the launcher is missing or unusable, the entries should say so with an Apktool remediation.

Restoration check: in the same session, the per-tool facts (expanded from groups where applicable) report inspect_apktool_client and decode_android_resources available. With REA_APKTOOL_COMMAND set to a nonexistent file, both entries are unavailable with an Apktool remediation. Control: the android-provider entries still track the JADX JAR and JDK as they do today.

Impact and scope

Affected: the two apktool-provider entries in binary_session.tool_availability, on both builds, whatever the Apktool configuration. Agents that follow the documented availability contract are told that both Apktool tools are unavailable while Apktool is configured, and inspect_apktool_client was observed succeeding in the same session, so agents may skip resource decoding.

Not affected: the Apktool tools themselves run when called; no data is lost.

Workaround: call inspect_apktool_client directly to see the real Apktool state (observed on both builds).

REA version

6.4.0 (npm, tag rea-agents-6.4.0 at a56f7bb668); also reproduced from source at main e049ef70f7

Runtime and platform

Node 26.10.0; macOS 27.0 arm64; Apktool 3.0.3 release JAR run through a launcher script on Temurin JDK 21.0.12.1

Target and artifact context

No target or APK; target-free binary_session call

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

binary_session (6.4.0), both apktool-provider entries:
{"available":false,"reason":"provider_missing","remediation":"Install or configure a provider that declares this operation."}

inspect_apktool_client (same server), selected fields:
isError=false provider {"id":"apktool","name":"Apktool","version":"3.0.3"} normalized_result.client.command_source "environment"

Analysis or suspected cause

Source-derived, consistent with the runs on both builds: AvailabilityPolicy in src/application/CapabilityInventory.ts (lines 34-51 at the tag, 45-65 on main) has no Apktool field, and the per-kind checks have no apktool-provider branch, so these tools reach the descriptor fallback in providerAvailability (lines 491-518 at the tag, 604-631 on main), which returns provider_missing with the generic remediation.

Additional context

The same binary_session result also misreports the ADB and JEB tools; each is reported separately because each engine has its own configuration, readiness tool, and restoration signal. Related but separate: #3008 asks rea doctor to report these providers; this report concerns binary_session.tool_availability.

Originally created by @coygeek on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3068 ### 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 `binary_session` reports both Apktool tools as unavailable with `reason: "provider_missing"` and a generic remediation, even when `REA_APKTOOL_COMMAND` points at a working Apktool launcher. In the same MCP session, `inspect_apktool_client` succeeds. Agents that choose operations from `tool_availability`, as the MCP contract instructs, are told Android resource decoding cannot run while Apktool is configured. Android/JADX entries already follow their engine's readiness (fixed in #1124). On 6.4.0, `binary_session` listed both `apktool-provider` tools (`decode_android_resources`, `inspect_apktool_client`) as `available: false`, `reason: "provider_missing"`, remediation "Install or configure a provider that declares this operation.". `inspect_apktool_client` in the same server then succeeded and reported Apktool `3.0.3` with `command_source: "environment"`. The `main` build gave the same per-tool facts in grouped form: both `apktool-provider` groups had `available: false`, `reason: "provider_missing"`, and the same generic remediation, and `inspect_apktool_client` again succeeded. The entries do not change with configuration: in runs on both builds with `REA_APKTOOL_COMMAND` unset (and `apktool` not on `PATH`), both Apktool entries were identical, while `inspect_apktool_client` then failed with `capability_unavailable`. An earlier run of 6.4.0 with Apktool 2.7.0, the version `docs/apktool-resource-analysis.md` names as verified, reported the same entries; that run was not repeated for this report. `decode_android_resources` was not run, because no APK was used. ### Reproduction 1. Create an Apktool launcher (for example a shell script that runs `java -jar apktool.jar "$@"`), then start the server with it configured: `REA_APKTOOL_COMMAND=/abs/apktool npx -y rea-agents@6.4.0 mcp`. No APK or open target is needed. For the `main` build, start `node scripts/rea.mjs mcp` from the compiled checkout (`npm ci --ignore-scripts`, `npm run compile`) with the same environment instead. 2. From a stdio MCP client, send these newline-delimited messages in order, waiting for the `initialize` response before sending the rest. ```json {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"availability-probe","version":"1.0.0"}}} {"jsonrpc":"2.0","method":"notifications/initialized"} {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"binary_session","arguments":{}}} {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"inspect_apktool_client","arguments":{}}} ``` 3. In response 2, read `result.structuredContent.result.tool_availability` and select the entries whose surface is `apktool-provider`. On `main`, expand `tool_availability.groups` into per-tool entries first. 4. Compare those entries with response 3. ### Expected behavior `docs/mcp-contracts.md` (lines 114-119 at the 6.4.0 tag; lines 337-347 on `main` in grouped form) says: "Call `binary_session` with `{}` and read `result.tool_availability` to choose a callable operation for the current target, provider, host, and negotiated client capabilities", with each tool's availability, reason, and remediation. The Apktool tools need no `open_binary` target; `decode_android_resources` takes its APK as a `path` argument. With the launcher configured and callable, `inspect_apktool_client` and `decode_android_resources` should be reported available, as the `android-provider` tools are when the JADX JAR and JDK are ready. When the launcher is missing or unusable, the entries should say so with an Apktool remediation. Restoration check: in the same session, the per-tool facts (expanded from groups where applicable) report `inspect_apktool_client` and `decode_android_resources` available. With `REA_APKTOOL_COMMAND` set to a nonexistent file, both entries are unavailable with an Apktool remediation. Control: the `android-provider` entries still track the JADX JAR and JDK as they do today. ### Impact and scope Affected: the two `apktool-provider` entries in `binary_session.tool_availability`, on both builds, whatever the Apktool configuration. Agents that follow the documented availability contract are told that both Apktool tools are unavailable while Apktool is configured, and `inspect_apktool_client` was observed succeeding in the same session, so agents may skip resource decoding. Not affected: the Apktool tools themselves run when called; no data is lost. Workaround: call `inspect_apktool_client` directly to see the real Apktool state (observed on both builds). ### REA version 6.4.0 (npm, tag rea-agents-6.4.0 at a56f7bb668ab23fec8d33f7af353ac7ed2fe1895); also reproduced from source at main e049ef70f71aeb9965e9d75d4d4a84ea02eaee11 ### Runtime and platform Node 26.10.0; macOS 27.0 arm64; Apktool 3.0.3 release JAR run through a launcher script on Temurin JDK 21.0.12.1 ### Target and artifact context No target or APK; target-free `binary_session` call ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence ```text binary_session (6.4.0), both apktool-provider entries: {"available":false,"reason":"provider_missing","remediation":"Install or configure a provider that declares this operation."} inspect_apktool_client (same server), selected fields: isError=false provider {"id":"apktool","name":"Apktool","version":"3.0.3"} normalized_result.client.command_source "environment" ``` ### Analysis or suspected cause Source-derived, consistent with the runs on both builds: `AvailabilityPolicy` in `src/application/CapabilityInventory.ts` (lines 34-51 at the tag, 45-65 on `main`) has no Apktool field, and the per-kind checks have no `apktool-provider` branch, so these tools reach the descriptor fallback in `providerAvailability` (lines 491-518 at the tag, 604-631 on `main`), which returns `provider_missing` with the generic remediation. ### Additional context The same `binary_session` result also misreports the ADB and JEB tools; each is reported separately because each engine has its own configuration, readiness tool, and restoration signal. Related but separate: #3008 asks `rea doctor` to report these providers; this report concerns `binary_session.tool_availability`.

bsakaguchi

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

closed this issue
added the
bug
label

bsakaguchi referenced this issue

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

[PR #1074] [MERGED] fix(evidence): report missing evidence files instead of permission advice #2623

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

No description provided.

Rows
Columns