[GH-ISSUE #5086] [Bug] EVM discovery reports available when its required prlimit executable is absent #3121

Closed
opened 2026-10-31 00:36:52 +00:00 by bsakaguchi · 4 comments
Owner

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

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

SOURCE-ONLY: the default MCP session marks inspect_evm_interface available on Linux x64 regardless of whether its required limiter exists. The provider independently rejects a missing selected prlimit executable before reading the carrier or launching its worker. Thus discovery reports available: true, reason: "available", and null remediation for a host where execution cannot proceed.

No Linux runtime, inventory response or execution error was captured. This finding follows the complete production call path described below.

Reproduction

No runtime reproduction was performed. Source inspection established this case:

  1. Start the normal MCP session server on Linux x64 without a custom availability policy or injected EVM service. Let REA_EVM_PRLIMIT_COMMAND be unset and /usr/bin/prlimit absent.
  2. Request binary_session with {}. The default Linux x64 policy enables the EVM operation without checking the selected executable.
  3. Invoke inspect_evm_interface with a valid absolute local hex-carrier path, encoding: "hex", and omitted detail. The provider's mandatory executable check fails independently of the carrier's contents.

These are source-derived trigger conditions, not commands executed here. A runtime check can use a local file containing 00; it requires no chain endpoint or target execution.

Expected behavior

Discovery should reflect an absent mandatory host prerequisite, with actionable remediation, instead of advertising unconditional availability. The docs/mcp-contracts.md:346-354 directs callers to select callable operations for the current host using this inventory. The docs/evm-bytecode.md:20-26 explicitly requires util-linux prlimit and documents its default path and override.

This expectation does not require an override when the default executable works, nor does it guarantee validity of arbitrary artifact inputs.

Impact and scope

Source-derived scope: default Linux x64 MCP sessions whose selected limiter is absent. Callers relying on discovery receive a positive availability claim for an operation that must refuse at invocation. The failure is bounded to discovery and prerequisite admission; the execution path still refuses and explains the missing prerequisite. No data loss, evidence corruption or unsafe execution is claimed.

Providing util-linux prlimit at the documented default or an absolute override addresses this specific prerequisite by source; a successful restoration was not executed. Runtime prevalence and frequency are NOT_ENOUGH_INFO.

REA version

Source revision 3537e58c1ab29309f06eabf50bc52adba9817a0c, package version 6.7.0. Relevant policy, inventory, provider and guide files are identical to the rea-agents-6.7.0 tag. Released runtime behavior was not exercised.

Runtime and platform

Inspection host: Node v26.12.0, Darwin 27.0.0, arm64. Affected source branch: Linux x64. Supported Linux runtime reproduction: NOT_ENOUGH_INFO; not performed.

Target and artifact context

No artifact was analyzed. The source-derived trigger accepts an absolute local flat hex-bytecode carrier, such as a file containing 00. No wallet, deployed contract, network endpoint or third-party application is involved.

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

SOURCE-ONLY, obtained by reading the stated revision:

The relevant stable/main source comparison returned exit 0 and no differences. Runtime output is NOT_ENOUGH_INFO: no server or provider was run.

Typed outcome or recovery expected

An unavailable discovery entry with remediation identifying the missing util-linux limiter and REA_EVM_PRLIMIT_COMMAND, consistent with execution's prerequisite refusal. The precise unavailable reason is an implementation choice.

Analysis or suspected cause

Source-derived: availability records the supported platform while the mandatory executable check occurs only during invocation. Bundling EVMole does not supply the external limiter.

Additional context

No matching open or closed issue was found in the supplied complete issue snapshot. Related firmware prerequisite/doctor reports and offline HAR discovery concern different operations and closure conditions. No runtime coverage of Linux, stable-package execution, missing ps, or successful recovery is claimed.

Freshness review against 29910d16b98fe4b607a7aa15928789a73614b0b9: the intervening inventory edits change call-traversal and native-dispatch composition, while the EVM availability branch and the platform-only default policy and required prlimit admission path remain unchanged. The report remains valid by source proof. No Linux server/provider runtime was run for this freshness review; the original tested/inspected SHA and all runtime limits above remain unchanged.

Originally created by @coygeek on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5086 ## 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 SOURCE-ONLY: the default MCP session marks `inspect_evm_interface` available on Linux x64 regardless of whether its required limiter exists. The provider independently rejects a missing selected `prlimit` executable before reading the carrier or launching its worker. Thus discovery reports `available: true`, `reason: "available"`, and null remediation for a host where execution cannot proceed. No Linux runtime, inventory response or execution error was captured. This finding follows the complete production call path described below. ## Reproduction No runtime reproduction was performed. Source inspection established this case: 1. Start the normal MCP session server on Linux x64 without a custom availability policy or injected EVM service. Let `REA_EVM_PRLIMIT_COMMAND` be unset and `/usr/bin/prlimit` absent. 2. Request `binary_session` with `{}`. The default Linux x64 policy enables the EVM operation without checking the selected executable. 3. Invoke `inspect_evm_interface` with a valid absolute local hex-carrier path, `encoding: "hex"`, and omitted `detail`. The provider's mandatory executable check fails independently of the carrier's contents. These are source-derived trigger conditions, not commands executed here. A runtime check can use a local file containing `00`; it requires no chain endpoint or target execution. ## Expected behavior Discovery should reflect an absent mandatory host prerequisite, with actionable remediation, instead of advertising unconditional availability. The [docs/mcp-contracts.md:346-354](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/docs/mcp-contracts.md#L346-L354) directs callers to select callable operations for the current host using this inventory. The [docs/evm-bytecode.md:20-26](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/docs/evm-bytecode.md#L20-L26) explicitly requires util-linux `prlimit` and documents its default path and override. This expectation does not require an override when the default executable works, nor does it guarantee validity of arbitrary artifact inputs. ## Impact and scope Source-derived scope: default Linux x64 MCP sessions whose selected limiter is absent. Callers relying on discovery receive a positive availability claim for an operation that must refuse at invocation. The failure is bounded to discovery and prerequisite admission; the execution path still refuses and explains the missing prerequisite. No data loss, evidence corruption or unsafe execution is claimed. Providing util-linux `prlimit` at the documented default or an absolute override addresses this specific prerequisite by source; a successful restoration was not executed. Runtime prevalence and frequency are NOT_ENOUGH_INFO. ## REA version Source revision `3537e58c1ab29309f06eabf50bc52adba9817a0c`, package version 6.7.0. Relevant policy, inventory, provider and guide files are identical to the `rea-agents-6.7.0` tag. Released runtime behavior was not exercised. ## Runtime and platform Inspection host: Node v26.12.0, Darwin 27.0.0, arm64. Affected source branch: Linux x64. Supported Linux runtime reproduction: NOT_ENOUGH_INFO; not performed. ## Target and artifact context No artifact was analyzed. The source-derived trigger accepts an absolute local flat hex-bytecode carrier, such as a file containing `00`. No wallet, deployed contract, network endpoint or third-party application is involved. ## Interface MCP ## Earliest failure stage Setup or provider admission ## Relevant output or evidence SOURCE-ONLY, obtained by reading the stated revision: - [src/main/transport.ts:114-129](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/main/transport.ts#L114-L129) constructs the normal session server. [src/server/createServer.ts:300-301](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/server/createServer.ts#L300-L301) selects the default EVM service; [src/composition/evm.ts:6-10](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/composition/evm.ts#L6-L10) constructs its real provider. - [src/server/createServer.ts:193-211](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/server/createServer.ts#L193-L211) sets the EVM flag from Linux x64 alone. [src/server/sessionAvailabilityPolicy.ts:34-44](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/server/sessionAvailabilityPolicy.ts#L34-L44) preserves the default. [src/server/createServer.ts:594-600](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/server/createServer.ts#L594-L600) passes it into session registration. - [src/server/registerSessionStatusTool.ts:93-110](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/server/registerSessionStatusTool.ts#L93-L110) builds the public inventory with that policy. [src/application/CapabilityInventory.ts:291-314](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/CapabilityInventory.ts#L291-L314) evaluates the workflow branch before host/target decisions; [src/application/CapabilityInventory.ts:435-442](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/CapabilityInventory.ts#L435-L442) returns available with null remediation. [src/application/CapabilityInventory.ts:212-227](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/CapabilityInventory.ts#L212-L227) emits the positive availability entry. - With valid input and omitted detail, [src/server/registerEvmTools.ts:30-50](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/server/registerEvmTools.ts#L30-L50) calls the shared service; [src/application/evm/EvmInterfaceService.ts:43-61](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/evm/EvmInterfaceService.ts#L43-L61) validates the absolute path and invokes the provider. - [src/evm/EvmoleInterfaceProvider.ts:189-221](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmoleInterfaceProvider.ts#L189-L221) selects the default/override limiter and rejects its absence with `AnalysisCapabilityUnavailableError`. This check precedes artifact reading and worker launch. [src/evm/EvmoleFailures.ts:43-50](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmoleFailures.ts#L43-L50) preserves typed analysis errors. The relevant stable/main source comparison returned exit 0 and no differences. Runtime output is NOT_ENOUGH_INFO: no server or provider was run. ## Typed outcome or recovery expected An unavailable discovery entry with remediation identifying the missing util-linux limiter and `REA_EVM_PRLIMIT_COMMAND`, consistent with execution's prerequisite refusal. The precise unavailable reason is an implementation choice. ## Analysis or suspected cause Source-derived: availability records the supported platform while the mandatory executable check occurs only during invocation. Bundling EVMole does not supply the external limiter. ## Additional context No matching open or closed issue was found in the supplied complete issue snapshot. Related firmware prerequisite/doctor reports and offline HAR discovery concern different operations and closure conditions. No runtime coverage of Linux, stable-package execution, missing `ps`, or successful recovery is claimed. Freshness review against `29910d16b98fe4b607a7aa15928789a73614b0b9`: the intervening inventory edits change call-traversal and native-dispatch composition, while the [EVM availability branch](https://github.com/morluto/rea/blob/29910d16b98fe4b607a7aa15928789a73614b0b9/src/application/CapabilityInventory.ts#L478-L485) and the platform-only default policy and required prlimit admission path remain unchanged. The report remains valid by source proof. No Linux server/provider runtime was run for this freshness review; the original tested/inspected SHA and all runtime limits above remain unchanged.
Author
Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

I'd like to take this one. Root cause looks clear: the inspect_evm_interface branch of CapabilityInventory reports available based only on the policy bit, while EvmoleInterfaceProvider independently hard-validates the selected prlimit executable (REA_EVM_PRLIMIT_COMMAND ?? /usr/bin/prlimit) at execution time. I'll make discovery run the same existence/executability check and return provider_missing with remediation when it fails, with unit tests injecting fs. Will follow up with a fix shortly.

<!-- gh-comment-id:6267416573 --> @akushonkamen commented on GitHub (Oct 19, 2026): I'd like to take this one. Root cause looks clear: the `inspect_evm_interface` branch of `CapabilityInventory` reports `available` based only on the policy bit, while `EvmoleInterfaceProvider` independently hard-validates the selected prlimit executable (`REA_EVM_PRLIMIT_COMMAND ?? /usr/bin/prlimit`) at execution time. I'll make discovery run the same existence/executability check and return `provider_missing` with remediation when it fails, with unit tests injecting fs. Will follow up with a fix shortly.
Author
Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Update: the fix is complete and pushed, but I could not open the PR against this repository — GitHub rejects pull-request creation for this fork with CreatePullRequest FORBIDDEN on both the REST and GraphQL APIs, while opening a PR from the same account on its own fork succeeds, so the restriction is specific to morluto/rea. The branch is ready for review at:

What it does:

  • CapabilityInventory no longer advertises inspect_evm_interface from the policy bit alone. The session availability policy (createServer, wired through composition/evm per the module-boundary guard) now probes the selected limiter — REA_EVM_PRLIMIT_COMMAND ?? /usr/bin/prlimit — with the same Linux x64 gate and existence/executability semantics as EvmoleInterfaceProvider's mandatory execution check (absolute path, accessSync(X_OK), regular file), and records it as an optional evmLimiterAvailability policy fact.
  • When that probe is unavailable, discovery reports available: false, reason: "provider_missing" with the provider's own remediation wording. Non-Linux-x64 hosts return no probe and keep their existing gate; hosts with no recorded probe keep the prior behavior, so embedders and focused tests are unaffected.
  • Adds a process-free probe evmLimiterAvailability(environment, probes?) in EvmoleInterfaceProvider with injectable fs/platform for tests; the default prlimit path is now a single shared constant used by both execution and discovery. Docs needed no edits: docs/evm-bytecode.md already requires util-linux prlimit at the documented default or an absolute override — exactly what discovery now reports when it is missing.

Verification: new tests first reproduced the red state (with an unavailable limiter probe recorded, the entry still came back available: true, reason: "available", remediation: null) and pass after the fix (7 probe cases + 3 inventory cases). Regression: src/application (96 files, 1317 tests), src/evm (61), src/server (23), plus the composition/boundary/acceptance EVM-related subsets — all pass; typecheck, lint, format, and knip pass. Unrelated host flakes (ghidra cleanup, production-child catalog probes) were confirmed identical on a stashed baseline.

If PR creation from this fork can be allowed, I'll open the PR immediately; otherwise feel free to open one from the branch above.

<!-- gh-comment-id:6268463294 --> @akushonkamen commented on GitHub (Oct 19, 2026): Update: the fix is complete and pushed, but I could not open the PR against this repository — GitHub rejects pull-request creation for this fork with `CreatePullRequest` FORBIDDEN on both the REST and GraphQL APIs, while opening a PR from the same account on its own fork succeeds, so the restriction is specific to morluto/rea. The branch is ready for review at: - https://github.com/akushonkamen/rea/tree/fix/5086-evm-discovery-prlimit (commit e24db02f26447de84e68039112fb36dddee8eb6d, based on current main 3ea0d9489) What it does: - `CapabilityInventory` no longer advertises `inspect_evm_interface` from the policy bit alone. The session availability policy (`createServer`, wired through `composition/evm` per the module-boundary guard) now probes the selected limiter — `REA_EVM_PRLIMIT_COMMAND ?? /usr/bin/prlimit` — with the same Linux x64 gate and existence/executability semantics as `EvmoleInterfaceProvider`'s mandatory execution check (absolute path, `accessSync(X_OK)`, regular file), and records it as an optional `evmLimiterAvailability` policy fact. - When that probe is unavailable, discovery reports `available: false, reason: "provider_missing"` with the provider's own remediation wording. Non-Linux-x64 hosts return no probe and keep their existing gate; hosts with no recorded probe keep the prior behavior, so embedders and focused tests are unaffected. - Adds a process-free probe `evmLimiterAvailability(environment, probes?)` in `EvmoleInterfaceProvider` with injectable fs/platform for tests; the default prlimit path is now a single shared constant used by both execution and discovery. Docs needed no edits: docs/evm-bytecode.md already requires util-linux `prlimit` at the documented default or an absolute override — exactly what discovery now reports when it is missing. Verification: new tests first reproduced the red state (with an unavailable limiter probe recorded, the entry still came back `available: true, reason: "available", remediation: null`) and pass after the fix (7 probe cases + 3 inventory cases). Regression: `src/application` (96 files, 1317 tests), `src/evm` (61), `src/server` (23), plus the composition/boundary/acceptance EVM-related subsets — all pass; typecheck, lint, format, and knip pass. Unrelated host flakes (ghidra cleanup, production-child catalog probes) were confirmed identical on a stashed baseline. If PR creation from this fork can be allowed, I'll open the PR immediately; otherwise feel free to open one from the branch above.
Author
Owner

@CassieFox23 commented on GitHub (Oct 20, 2026):

TL;DR: This looks fixed on main. Closing is the maintainers' call.

Checked on main b3aadaf47 (Linux, Node 24.18.0). With REA_EVM_PRLIMIT_COMMAND pointing at a file that does not exist, binary_session now lists inspect_evm_interface as available: false, provider_missing, with remediation text. With the default limiter it stays available. This matches the fix in a74d859a1.

Not run

  • Removing /usr/bin/prlimit itself. A missing override path stood in for it.
  • Calling inspect_evm_interface.

Thanks, coygeek, for the clear report.

Commands

A small Node script started node scripts/rea.mjs mcp over stdio and called tools/call binary_session {}, once with the default environment and once with REA_EVM_PRLIMIT_COMMAND=/tmp/no-such-prlimit.

  • Default: inspect_evm_interface (grouped with inspect_sqlite_database) available: true, reason: "available"
  • Missing limiter: inspect_evm_interface available: false, reason: "provider_missing", remediation "Offline EVM interface inspection requires caller-supplied util-linux prlimit: ... ENOENT: no such file or directory"

Both runs exit 0. node scripts/rea.mjs capabilities --json does not list this tool, so it was not used.

Test setup
  • Box: Nobara 44 (Fedora 44 base), Linux 7.2.11
  • CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
  • RAM: 32 GB DDR4-3600
  • Node: 24.18.0
  • Head: b3aadaf47
  • Other: another job shared the box during the run

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

<!-- gh-comment-id:6298145542 --> @CassieFox23 commented on GitHub (Oct 20, 2026): **TL;DR:** This looks fixed on main. Closing is the maintainers' call. Checked on main b3aadaf47 (Linux, Node 24.18.0). With `REA_EVM_PRLIMIT_COMMAND` pointing at a file that does not exist, `binary_session` now lists `inspect_evm_interface` as `available: false`, `provider_missing`, with remediation text. With the default limiter it stays available. This matches the fix in a74d859a1. ### Not run - Removing `/usr/bin/prlimit` itself. A missing override path stood in for it. - Calling `inspect_evm_interface`. Thanks, coygeek, for the clear report. <details> <summary>Commands</summary> A small Node script started `node scripts/rea.mjs mcp` over stdio and called `tools/call binary_session {}`, once with the default environment and once with `REA_EVM_PRLIMIT_COMMAND=/tmp/no-such-prlimit`. - Default: `inspect_evm_interface` (grouped with `inspect_sqlite_database`) `available: true`, `reason: "available"` - Missing limiter: `inspect_evm_interface` `available: false`, `reason: "provider_missing"`, remediation "Offline EVM interface inspection requires caller-supplied util-linux prlimit: ... ENOENT: no such file or directory" Both runs exit 0. `node scripts/rea.mjs capabilities --json` does not list this tool, so it was not used. </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.11 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head: b3aadaf47 - Other: another job shared the box during the run </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊
Author
Owner

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

Closing as fixed on main by github.com/morluto/rea@a74d859a19, retained at 67a6477f01.

EVM capability discovery now probes the same selected limiter executable used by execution and returns provider_missing with remediation when it is unavailable. Provider and MCP inventory regressions cover missing/default/explicit limiter selection. This closes the availability-reporting defect without claiming an additional EVM worker run.

This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

<!-- gh-comment-id:6324283391 --> @morluto commented on GitHub (Oct 21, 2026): Closing as fixed on main by https://github.com/morluto/rea/commit/a74d859a19122fb8f1282b3632d320997b1caae0, retained at 67a6477f011ae358fc333e5a6e26c86d932654ed. EVM capability discovery now probes the same selected limiter executable used by execution and returns provider_missing with remediation when it is unavailable. Provider and MCP inventory regressions cover missing/default/explicit limiter selection. This closes the availability-reporting defect without claiming an additional EVM worker run. This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.
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#3121
No description provided.