[GH-ISSUE #8508] [Bug] EVM limiter configuration failures expose internal codes as recovery guidance #6633

Closed
opened 2026-11-01 21:12:49 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8508

Before submitting

  • Searched open and closed issues for related reports.
  • No credentials, private samples or sensitive target data.

Area

Provider or capability discovery

Observed behavior

An invalid REA_EVM_PRLIMIT_COMMAND produces a raw internal code as the final recovery instruction for inspect_evm_interface:

Selected value Availability code Final capability remediation
Relative prlimit executable_missing prlimit_not_absolute
Existing searchable directory executable_missing prlimit_not_file
Existing non-executable regular file executable_missing Description containing EACCES, without a specific repair action

These are different failures from a missing installation. The relative-path and directory cases give callers no readable next step or setting to correct in the final capability entry.

Reproduction

Executed the source readiness owner and its real inventory consumer, using temporary files/directories and the supported Linux/x64 probe override:

const availability = await evmLimiterAvailability(
  { REA_EVM_PRLIMIT_COMMAND: selectedPath },
  { platform: "linux", arch: "x64" },
);
const inventory = buildCapabilityInventory(
  { open: false, capabilities: [] },
  {
    processCaptureEnabled: true,
    evmInterfaceEnabled: true,
    evmLimiterAvailability: availability,
  },
);
console.log(inventory.find(entry => entry.name === "inspect_evm_interface"));

Inputs were prlimit, a newly created directory, a mode-0600 file, a nonexistent child path, and a mode-0700 file. Real filesystem checks ran; no filesystem implementation was injected. Each case was executed once on current main; relative/directory/missing cases also reproduced in the earlier audit. Fixtures were removed afterward.

Controls: the nonexistent path retains an explicit ENOENT description. The executable regular file passes the filesystem-only readiness check. That file was not executed and does not establish util-linux compatibility.

Expected behavior

Keep configuration-shape and permission failures distinguishable from absence. For relative or directory selection, explain that REA_EVM_PRLIMIT_COMMAND must select an absolute executable regular file for util-linux prlimit. For denied access, identify the selected path and the permission blocker. Preserve caller selection; do not silently substitute another command or install unrelated tools.

The recovery contract requires guidance derived from the actual failure. Any taxonomy adjustment should be made at its owning contract rather than adding string parsing to inventory.

Impact and scope

Discovery correctly refuses these inputs, but its next action is incomplete or cryptic. An agent may treat a wrong selection as missing software. No agent behavior, user frequency, target corruption or process-isolation failure was measured.

REA version

Source bafe3784cd6fd3f46dd472a913e97f08f4d7427f (package 6.8.0).

Runtime and platform

Node 24.22.1, Darwin arm64. Linux/x64 was supplied only through the existing readiness probe override. NOT_ENOUGH_INFO: native Linux CLI/MCP execution; no Linux runtime was available.

Target and artifact context

No EVM artifact opened and no limiter or worker launched.

Interface

Other: shared readiness and capability inventory consumed by CLI/MCP.

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Relative selection returns status: unavailable, code: executable_missing, reason: prlimit_not_absolute; its inventory entry returns available: false, reason: provider_missing, remediation: prlimit_not_absolute. Directory selection substitutes prlimit_not_file.

Source-derived cause: selectEvmLimiter sets reason to EvmAdmissionError.code; availability maps every failure to executable_missing. CapabilityInventory copies that reason into remediation. Execution uses the same selection reason, but its Linux execution projection was not run here.

Additional context and proposed checks

  • #5086 fixed availability when the limiter is absent. This report concerns invalid configured selections and readable recovery, not that former false-availability bug.
  • #7292 addressed limiter admission/attribution in pcap. Current pcap and firmware owners provide readable absolute-path constraints; WABT has a dedicated configuration recovery projection. Searching reason: cause.code found this conversion only in EVM. Hopper/Kuna also use the coarse executable_missing category for unusable paths, but retain readable descriptions; they are not claimed to have the same raw-code recovery defect.
  • External comparison: Context7/DeepWiki research was checked against uv's interpreter error owner, which retains distinct not-found, permission and spawn failures with the requested path. This supports preserving failure facts; uv's installation/fallback policies are not proposed for REA.
  • Proposed regression: cover relative, directory, permission-denied, absent and usable limiter selections through final discovery output; on Linux, follow the suggested repair and rerun the same operation. Preserve cancellation and explicit command selection. No implementation fix or real-engine recovery was tested.
Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8508 ### Before submitting - [x] Searched open and closed issues for related reports. - [x] No credentials, private samples or sensitive target data. ### Area Provider or capability discovery ### Observed behavior An invalid `REA_EVM_PRLIMIT_COMMAND` produces a raw internal code as the final recovery instruction for `inspect_evm_interface`: | Selected value | Availability code | Final capability remediation | | --- | --- | --- | | Relative `prlimit` | `executable_missing` | `prlimit_not_absolute` | | Existing searchable directory | `executable_missing` | `prlimit_not_file` | | Existing non-executable regular file | `executable_missing` | Description containing `EACCES`, without a specific repair action | These are different failures from a missing installation. The relative-path and directory cases give callers no readable next step or setting to correct in the final capability entry. ### Reproduction Executed the source readiness owner and its real inventory consumer, using temporary files/directories and the supported Linux/x64 probe override: ```ts const availability = await evmLimiterAvailability( { REA_EVM_PRLIMIT_COMMAND: selectedPath }, { platform: "linux", arch: "x64" }, ); const inventory = buildCapabilityInventory( { open: false, capabilities: [] }, { processCaptureEnabled: true, evmInterfaceEnabled: true, evmLimiterAvailability: availability, }, ); console.log(inventory.find(entry => entry.name === "inspect_evm_interface")); ``` Inputs were `prlimit`, a newly created directory, a mode-0600 file, a nonexistent child path, and a mode-0700 file. Real filesystem checks ran; no filesystem implementation was injected. Each case was executed once on current main; relative/directory/missing cases also reproduced in the earlier audit. Fixtures were removed afterward. Controls: the nonexistent path retains an explicit `ENOENT` description. The executable regular file passes the filesystem-only readiness check. That file was not executed and does not establish util-linux compatibility. ### Expected behavior Keep configuration-shape and permission failures distinguishable from absence. For relative or directory selection, explain that `REA_EVM_PRLIMIT_COMMAND` must select an absolute executable regular file for util-linux prlimit. For denied access, identify the selected path and the permission blocker. Preserve caller selection; do not silently substitute another command or install unrelated tools. The [recovery contract](https://github.com/morluto/rea/blob/d684125eedc75ea3ea6061d086ae9c530da198a4/docs/tool-design.md#design-recovery-around-the-failure) requires guidance derived from the actual failure. Any taxonomy adjustment should be made at its owning contract rather than adding string parsing to inventory. ### Impact and scope Discovery correctly refuses these inputs, but its next action is incomplete or cryptic. An agent may treat a wrong selection as missing software. No agent behavior, user frequency, target corruption or process-isolation failure was measured. ### REA version Source `bafe3784cd6fd3f46dd472a913e97f08f4d7427f` (package 6.8.0). ### Runtime and platform Node 24.22.1, Darwin arm64. Linux/x64 was supplied only through the existing readiness probe override. NOT_ENOUGH_INFO: native Linux CLI/MCP execution; no Linux runtime was available. ### Target and artifact context No EVM artifact opened and no limiter or worker launched. ### Interface Other: shared readiness and capability inventory consumed by CLI/MCP. ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Relative selection returns `status: unavailable`, `code: executable_missing`, `reason: prlimit_not_absolute`; its inventory entry returns `available: false`, `reason: provider_missing`, `remediation: prlimit_not_absolute`. Directory selection substitutes `prlimit_not_file`. Source-derived cause: [`selectEvmLimiter`](https://github.com/morluto/rea/blob/bafe3784cd6fd3f46dd472a913e97f08f4d7427f/src/evm/EvmoleInterfaceProvider.ts#L123) sets `reason` to `EvmAdmissionError.code`; availability maps every failure to `executable_missing`. [`CapabilityInventory`](https://github.com/morluto/rea/blob/bafe3784cd6fd3f46dd472a913e97f08f4d7427f/src/application/CapabilityInventory.ts#L572) copies that reason into remediation. Execution uses the same selection reason, but its Linux execution projection was not run here. ### Additional context and proposed checks - #5086 fixed availability when the limiter is absent. This report concerns invalid configured selections and readable recovery, not that former false-availability bug. - #7292 addressed limiter admission/attribution in pcap. Current pcap and firmware owners provide readable absolute-path constraints; WABT has a dedicated configuration recovery projection. Searching `reason: cause.code` found this conversion only in EVM. Hopper/Kuna also use the coarse `executable_missing` category for unusable paths, but retain readable descriptions; they are not claimed to have the same raw-code recovery defect. - External comparison: Context7/DeepWiki research was checked against [uv's interpreter error owner](https://github.com/astral-sh/uv/blob/564a2074b02eb9de5aaaa9491ed74357ade0332f/crates/uv-python-interpreter/src/interpreter.rs#L998), which retains distinct not-found, permission and spawn failures with the requested path. This supports preserving failure facts; uv's installation/fallback policies are not proposed for REA. - Proposed regression: cover relative, directory, permission-denied, absent and usable limiter selections through final discovery output; on Linux, follow the suggested repair and rerun the same operation. Preserve cancellation and explicit command selection. No implementation fix or real-engine recovery was tested.
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#6633
No description provided.