morluto/rea

Fork 0

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

[GH-ISSUE #8657] [Bug] Scoped direct tools suggest disabled open_binary for a missing target #7504

New issue

Open

opened 2026-11-03 00:30:18 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-03 00:30:18 +00:00

Owner

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

Before submitting

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

Area

MCP or agent integration

Observed behavior

With REA_MCP_TOOL_FAMILIES=direct, tools/list advertises read_bytes but not open_binary, binary_session, or close_binary. Calling read_bytes without an open target returns target_unavailable and tells the caller: “No app is open. Ask the user which app to investigate, then call open_binary with its local path.” Calling open_binary instead returns the SDK error Tool open_binary disabled. The recovery points to an operation the current connection cannot invoke.

Reproduction

Start stdio MCP with REA_MCP_TOOL_FAMILIES=direct and fetch tools/list.
Call read_bytes with {"address":"0x1000002d8","length":8}; observe the no-target error and advice to call open_binary.
Attempt open_binary; the SDK reports it disabled. binary_session and close_binary are disabled as well.
Control: restart with REA_MCP_TOOL_FAMILIES=session,direct. open_binary with a self-owned Mach-O and provider_id: "kuna" succeeds. Calling read_bytes then returns the provider-specific unsupported-operation guidance; binary_session(detail: "complete") is callable.

Retained Evidence before a scope restart

On PR #8659, a real direct,native,application stdio session ran a target-free inspect_native_exports with summary detail, then returned the scoped no-target refusal from read_bytes. Its parent Evidence was available through inspect_analysis_view, but the session family (including export_evidence_bundle) was not advertised. After restarting with session added, that retained reference was missing. This is why the recovery warns to preserve needed outputs before restarting.

For this one stable local ELF, rerunning the producer with complete detail before the restart returned the same parent Evidence ID. I saved that complete returned record as a local JSON file and, in the new session, inspect_analysis_view using an evidence-file source successfully authenticated and queried the record. This manual handoff required a separate local file write and a repeated producer call; it is not a general guarantee for other operations, changing inputs, large responses, or clients without file-writing access. The separate preservation design is tracked in #8682, including whether scoped connections should expose a bounded route for retained records without enabling all session lifecycle tools. A further production-registration in-process MCP control used two real JavaScript analysis Evidence records for a partial export-shape comparison. With session scoped out, the owning session contained one linked Unknown while list_unknowns and export were not advertised. This verifies the hidden record through the session owner, not through external stdio; a separate session-enabled stdio control listed the same Unknown. A restart therefore risks losing Unknown history as well as retained Evidence.

Expected behavior

When this MCP connection omits the session family, report that the requested operation has no open target and explain that the caller can add session to REA_MCP_TOOL_FAMILIES and restart before opening a target. Do not suggest changing the registration automatically or asking for a path when a path is already known. Preserve normal target-free and unscoped behavior, and avoid treating an excluded family as a missing provider. Exact UX remains open.

Impact and scope

A scoped agent cannot follow the supplied recovery in this reproduced configuration. I did not run autonomous-agent trials or establish frequency. The working control used one unexecuted, self-owned arm64 Mach-O; its source digest was unchanged. This is a concrete no-target error case related to the broader scoped-catalog discoverability discussion in #8388 and unsupported-provider recovery in #8565.

REA version

PR #8567 head da62c6aa3661a94d9f3d477733e724c5b7bf00c4; source inspection identifies the general no-target error in src/domain/configurationErrors.ts. Current main behavior has not been separately run.

Runtime and platform

Node 24.22.1, macOS arm64, Kuna 1.988, stdio MCP compact output profile.

Target

Self-owned ARM64 Mach-O, SHA-256 a6bd938bf4ae8031a33d270ca7698ee1ced5b78347a9c4fa3750b0e57f6b126c.

Additional context

The domain error cannot know the MCP family's scope. Any correction should use the registration's authoritative advertised scope at the transport boundary, rather than changing shared CLI/fixed-target behavior based on an assumed MCP configuration.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8657 ### Before submitting - [x] I searched open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Observed behavior With `REA_MCP_TOOL_FAMILIES=direct`, `tools/list` advertises `read_bytes` but not `open_binary`, `binary_session`, or `close_binary`. Calling `read_bytes` without an open target returns `target_unavailable` and tells the caller: “No app is open. Ask the user which app to investigate, then call open_binary with its local path.” Calling `open_binary` instead returns the SDK error `Tool open_binary disabled`. The recovery points to an operation the current connection cannot invoke. ### Reproduction 1. Start stdio MCP with `REA_MCP_TOOL_FAMILIES=direct` and fetch `tools/list`. 2. Call `read_bytes` with `{"address":"0x1000002d8","length":8}`; observe the no-target error and advice to call `open_binary`. 3. Attempt `open_binary`; the SDK reports it disabled. `binary_session` and `close_binary` are disabled as well. 4. Control: restart with `REA_MCP_TOOL_FAMILIES=session,direct`. `open_binary` with a self-owned Mach-O and `provider_id: "kuna"` succeeds. Calling `read_bytes` then returns the provider-specific unsupported-operation guidance; `binary_session(detail: "complete")` is callable. ### Retained Evidence before a scope restart On PR #8659, a real `direct,native,application` stdio session ran a target-free `inspect_native_exports` with summary detail, then returned the scoped no-target refusal from `read_bytes`. Its parent Evidence was available through `inspect_analysis_view`, but the `session` family (including `export_evidence_bundle`) was not advertised. After restarting with `session` added, that retained reference was missing. This is why the recovery warns to preserve needed outputs before restarting. For this one stable local ELF, rerunning the producer with complete detail before the restart returned the same parent Evidence ID. I saved that complete returned record as a local JSON file and, in the new session, `inspect_analysis_view` using an `evidence-file` source successfully authenticated and queried the record. This manual handoff required a separate local file write and a repeated producer call; it is not a general guarantee for other operations, changing inputs, large responses, or clients without file-writing access. The separate preservation design is tracked in #8682, including whether scoped connections should expose a bounded route for retained records without enabling all session lifecycle tools. A further production-registration in-process MCP control used two real JavaScript analysis Evidence records for a partial export-shape comparison. With `session` scoped out, the owning session contained one linked Unknown while `list_unknowns` and export were not advertised. This verifies the hidden record through the session owner, not through external stdio; a separate session-enabled stdio control listed the same Unknown. A restart therefore risks losing Unknown history as well as retained Evidence. ### Expected behavior When this MCP connection omits the session family, report that the requested operation has no open target and explain that the caller can add `session` to `REA_MCP_TOOL_FAMILIES` and restart before opening a target. Do not suggest changing the registration automatically or asking for a path when a path is already known. Preserve normal target-free and unscoped behavior, and avoid treating an excluded family as a missing provider. Exact UX remains open. ### Impact and scope A scoped agent cannot follow the supplied recovery in this reproduced configuration. I did not run autonomous-agent trials or establish frequency. The working control used one unexecuted, self-owned arm64 Mach-O; its source digest was unchanged. This is a concrete no-target error case related to the broader scoped-catalog discoverability discussion in #8388 and unsupported-provider recovery in #8565. ### REA version PR #8567 head `da62c6aa3661a94d9f3d477733e724c5b7bf00c4`; source inspection identifies the general no-target error in `src/domain/configurationErrors.ts`. Current main behavior has not been separately run. ### Runtime and platform Node 24.22.1, macOS arm64, Kuna 1.988, stdio MCP compact output profile. ### Target Self-owned ARM64 Mach-O, SHA-256 `a6bd938bf4ae8031a33d270ca7698ee1ced5b78347a9c4fa3750b0e57f6b126c`. ### Additional context The domain error cannot know the MCP family's scope. Any correction should use the registration's authoritative advertised scope at the transport boundary, rather than changing shared CLI/fixed-target behavior based on an assumed MCP configuration. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

2026-11-03 00:30:18 +00:00

bsakaguchi commented

2026-11-03 14:29:00 +00:00

Author

Owner

@akshad-exe commented on GitHub (Nov 3, 2026):

This looks resolved on main by #8659 (6259ac41a, merged 2026-11-03), which added SCOPED_NO_TARGET_RECOVERY and selects it when the advertised families omit session:

const delivery =
  session !== undefined &&
  advertisedToolFamilies !== undefined &&
  !advertisedToolFamilies.has("session")
    ? baseDelivery.withNoTargetRecovery(SCOPED_NO_TARGET_RECOVERY)
    : baseDelivery;

The remediation now names the actual constraint rather than advising a disabled tool: "No target is open, and this MCP connection does not advertise open_binary. Preserve needed outputs before restarting; retained in-memory Evidence and Unknown history will not carry over. Add session to REA_MCP_TOOL_FAMILIES in the environment that starts REA and restart the server; then call open_binary with the chosen local path."

Verified on main at 8c857ce56 by running the regression #8659 added:

npm run test:focused -- tests/boundary/mcp/targetContentFramingMcp.test.ts
→ 15 passed
   ✓ guides a missing target using the advertised scope (direct)
   ✓ guides a missing target using the advertised scope (session,direct)
   ✓ guides a missing target using the advertised scope (undefined)

The direct case is this report's exact scope, and it asserts the target_unavailable error message and remediation equal SCOPED_NO_TARGET_RECOVERY and mention both REA_MCP_TOOL_FAMILIES and open_binary. A separate test covers the retained-Evidence warning before a scoped restart.

Not verified here: the original repro with a real open_binary attempt and a retained inspect_native_exports Evidence reference. Those are source and regression-test facts only.

If this matches your view, this issue can likely be closed as fixed by #8659. Happy to help if you see a remaining gap.

@akshad-exe commented on GitHub (Nov 3, 2026): This looks resolved on `main` by #8659 (`6259ac41a`, merged 2026-11-03), which added `SCOPED_NO_TARGET_RECOVERY` and selects it when the advertised families omit `session`: ```ts const delivery = session !== undefined && advertisedToolFamilies !== undefined && !advertisedToolFamilies.has("session") ? baseDelivery.withNoTargetRecovery(SCOPED_NO_TARGET_RECOVERY) : baseDelivery; ``` The remediation now names the actual constraint rather than advising a disabled tool: *"No target is open, and this MCP connection does not advertise open_binary. Preserve needed outputs before restarting; retained in-memory Evidence and Unknown history will not carry over. Add session to REA_MCP_TOOL_FAMILIES in the environment that starts REA and restart the server; then call open_binary with the chosen local path."* Verified on `main` at `8c857ce56` by running the regression #8659 added: ```text npm run test:focused -- tests/boundary/mcp/targetContentFramingMcp.test.ts → 15 passed ✓ guides a missing target using the advertised scope (direct) ✓ guides a missing target using the advertised scope (session,direct) ✓ guides a missing target using the advertised scope (undefined) ``` The `direct` case is this report's exact scope, and it asserts the `target_unavailable` error message and remediation equal `SCOPED_NO_TARGET_RECOVERY` and mention both `REA_MCP_TOOL_FAMILIES` and `open_binary`. A separate test covers the retained-Evidence warning before a scoped restart. Not verified here: the original repro with a real `open_binary` attempt and a retained `inspect_native_exports` Evidence reference. Those are source and regression-test facts only. If this matches your view, this issue can likely be closed as fixed by #8659. Happy to help if you see a remaining gap.

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

No description provided.

Rows
Columns