[GH-ISSUE #1166] [Bug] `binary_session` marks target-dependent tools available with no open target #409

New issue

Closed

opened 2026-10-15 18:24:50 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:24:50 +00:00

Owner

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

Before submitting

I searched the 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

MCP clients are told to call binary_session and read tool_availability to choose a callable operation. With no target open (on a fresh connection, and again after open_binary then close_binary), it reports inspect_macho, inspect_signature, list_architectures, and inspect_artifact as available: true with reason: "available" and no remediation. Calling any of them with their valid empty input then fails with target_unavailable ("No app is open"). The same mismatch appears with the wrong kind of target open: after opening a ZIP archive, inspect_macho is still advertised as available but fails with capability_unavailable ("Active artifact is not Mach-O."). Agents that follow the discovery contract pick operations that cannot run.

In both the fresh and closed states, all four entries are:

{"name":"inspect_macho","available":true,"reason":"available","remediation":null}

and each call returns isError: true with:

{"code":"target_unavailable","category":"unavailable","message":"No app is open. Ask the user which app to investigate, then call open_binary with its local path.","retryable":false}

Reproduced in three separate sessions on the npm release and once on the main build with the raw JSON-RPC client. With a thin Mach-O open (lipo /bin/ls -thin arm64e -output ls-arm64e), all four are reported available and all four calls succeed. With the universal /bin/ls itself open, inspect_artifact fails for an unrelated reason covered by a separate report (arm64e.x1 integrity mismatch). The ZIP case in the Summary (a ZIP archive opened with open_binary, then inspect_macho advertised available but failing with capability_unavailable and details.reason "Active artifact is not Mach-O.") was observed on the npm release only.

Reproduction

mkdir rea-availability && cd rea-availability
npm install @modelcontextprotocol/client@2.3.1
cat > repro.mjs <<'EOF'
import {Client} from '@modelcontextprotocol/client';
import {StdioClientTransport} from '@modelcontextprotocol/client/stdio';
const tools=['inspect_macho','inspect_signature','list_architectures','inspect_artifact'];
const c=new Client({name:'availability-demo',version:'1.0'});
await c.connect(new StdioClientTransport({command:'npx',args:['-y','rea-agents@6.1.0','mcp'],env:{...process.env}}));
async function probe(label){
  const s=(await c.callTool({name:'binary_session',arguments:{}})).structuredContent.result;
  console.log(label, JSON.stringify({open:s.open, availability:s.tool_availability.filter(x=>tools.includes(x.name)).map(({name,available,reason,remediation})=>({name,available,reason,remediation}))}));
  for (const name of tools){ const r=await c.callTool({name,arguments:{}}); console.log(name, r.isError, r.structuredContent?.error?.code); }
}
await probe('fresh');
await c.callTool({name:'open_binary',arguments:{path:'/bin/ls'}});
await c.callTool({name:'close_binary',arguments:{}});
await probe('closed');
await c.close();
EOF
node repro.mjs

Expected behavior

docs/mcp-contracts.md: "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 four tools above take no path argument and operate on the active artifact, so with no target open they should be reported unavailable with a missing-target reason and an open_binary remediation; target-free tools keep reporting available.

Impact and scope

The discovery result an agent is told to rely on is wrong for four common inspection tools, causing predictable failed calls; the tools themselves work once a target is open, and the error message says how to recover.

Workaround: Opening a supported, inspectable target with open_binary before calling these tools gets a correct result, as the thin Mach-O control shows; the target_unavailable message tells the agent to do this.

REA version

rea-agents@6.1.0 from npm, and main at 089bbf58f3 built locally with npm ci && npm run build:cached, started as rea mcp over stdio.

Runtime and platform

Node v24.21.0, macOS 27.0.1 (26A434), arm64. No Hopper, Ghidra, IDA, or Java installed.; Clients: @modelcontextprotocol/client 2.3.1, and a hand-written newline-delimited JSON-RPC client with no MCP SDK; both behave the same.

Target and artifact context

No open target; positive control is a thin arm64e Mach-O

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Expected source: docs/mcp-contracts.md, the binary_session discovery paragraph (unchanged on the main build), and the four tools' descriptions, which name the active artifact.
Failure source: the binary_session result and tool errors quoted under Observed behavior.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Typed outcome or recovery expected

Failing now: in a closed session, binary_session reports the four tools available while each call returns target_unavailable. Restored: in a closed session those entries report available: false with a missing-target reason and an open_binary remediation, and with the thin ls-arm64e copy open they report available and their calls succeed; with a non-Mach-O target open, inspect_macho is not reported available. Control: tools that accept an explicit path or need no target keep reporting available in a closed session, and tools/list stays unchanged across open and close.

Analysis or suspected cause

Source-derived, not verified by a patch: src/application/CapabilityInventory.ts applies its missing-target and unsupported-target checks only to the official-proxy and enhanced tool kinds, so artifact and native-metadata tools are reported available without a target descriptor.

Additional context

Found while exercising typical REA workflows on macOS with rea-agents@6.1.0; each case was reproduced on the npm release and on a local build of main, and re-checked on main at 6a1e558db3 just before filing.

Originally created by @coygeek on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1166 ### 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 MCP or agent integration ### Observed behavior MCP clients are told to call `binary_session` and read `tool_availability` to choose a callable operation. With no target open (on a fresh connection, and again after `open_binary` then `close_binary`), it reports `inspect_macho`, `inspect_signature`, `list_architectures`, and `inspect_artifact` as `available: true` with `reason: "available"` and no remediation. Calling any of them with their valid empty input then fails with `target_unavailable` ("No app is open"). The same mismatch appears with the wrong kind of target open: after opening a ZIP archive, `inspect_macho` is still advertised as available but fails with `capability_unavailable` ("Active artifact is not Mach-O."). Agents that follow the discovery contract pick operations that cannot run. In both the `fresh` and `closed` states, all four entries are: ```json {"name":"inspect_macho","available":true,"reason":"available","remediation":null} ``` and each call returns `isError: true` with: ```json {"code":"target_unavailable","category":"unavailable","message":"No app is open. Ask the user which app to investigate, then call open_binary with its local path.","retryable":false} ``` Reproduced in three separate sessions on the npm release and once on the `main` build with the raw JSON-RPC client. With a thin Mach-O open (`lipo /bin/ls -thin arm64e -output ls-arm64e`), all four are reported available and all four calls succeed. With the universal `/bin/ls` itself open, `inspect_artifact` fails for an unrelated reason covered by a separate report (`arm64e.x1` integrity mismatch). The ZIP case in the Summary (a ZIP archive opened with `open_binary`, then `inspect_macho` advertised available but failing with `capability_unavailable` and `details.reason` "Active artifact is not Mach-O.") was observed on the npm release only. ### Reproduction ```sh mkdir rea-availability && cd rea-availability npm install @modelcontextprotocol/client@2.3.1 cat > repro.mjs <<'EOF' import {Client} from '@modelcontextprotocol/client'; import {StdioClientTransport} from '@modelcontextprotocol/client/stdio'; const tools=['inspect_macho','inspect_signature','list_architectures','inspect_artifact']; const c=new Client({name:'availability-demo',version:'1.0'}); await c.connect(new StdioClientTransport({command:'npx',args:['-y','rea-agents@6.1.0','mcp'],env:{...process.env}})); async function probe(label){ const s=(await c.callTool({name:'binary_session',arguments:{}})).structuredContent.result; console.log(label, JSON.stringify({open:s.open, availability:s.tool_availability.filter(x=>tools.includes(x.name)).map(({name,available,reason,remediation})=>({name,available,reason,remediation}))})); for (const name of tools){ const r=await c.callTool({name,arguments:{}}); console.log(name, r.isError, r.structuredContent?.error?.code); } } await probe('fresh'); await c.callTool({name:'open_binary',arguments:{path:'/bin/ls'}}); await c.callTool({name:'close_binary',arguments:{}}); await probe('closed'); await c.close(); EOF node repro.mjs ``` ### Expected behavior `docs/mcp-contracts.md`: "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 four tools above take no path argument and operate on the active artifact, so with no target open they should be reported unavailable with a missing-target reason and an `open_binary` remediation; target-free tools keep reporting available. ### Impact and scope The discovery result an agent is told to rely on is wrong for four common inspection tools, causing predictable failed calls; the tools themselves work once a target is open, and the error message says how to recover. Workaround: Opening a supported, inspectable target with `open_binary` before calling these tools gets a correct result, as the thin Mach-O control shows; the `target_unavailable` message tells the agent to do this. ### REA version `rea-agents@6.1.0` from npm, and `main` at 089bbf58f3561e3f465c544bbcf8c307287b1256 built locally with `npm ci && npm run build:cached`, started as `rea mcp` over stdio. ### Runtime and platform Node v24.21.0, macOS 27.0.1 (26A434), arm64. No Hopper, Ghidra, IDA, or Java installed.; Clients: `@modelcontextprotocol/client` 2.3.1, and a hand-written newline-delimited JSON-RPC client with no MCP SDK; both behave the same. ### Target and artifact context No open target; positive control is a thin arm64e Mach-O ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence - Expected source: `docs/mcp-contracts.md`, the `binary_session` discovery paragraph (unchanged on the `main` build), and the four tools' descriptions, which name the active artifact. - Failure source: the `binary_session` result and tool errors quoted under Observed behavior. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete ### Typed outcome or recovery expected Failing now: in a closed session, `binary_session` reports the four tools available while each call returns `target_unavailable`. Restored: in a closed session those entries report `available: false` with a missing-target reason and an `open_binary` remediation, and with the thin `ls-arm64e` copy open they report available and their calls succeed; with a non-Mach-O target open, `inspect_macho` is not reported available. Control: tools that accept an explicit path or need no target keep reporting available in a closed session, and `tools/list` stays unchanged across open and close. ### Analysis or suspected cause Source-derived, not verified by a patch: `src/application/CapabilityInventory.ts` applies its missing-target and unsupported-target checks only to the `official-proxy` and `enhanced` tool kinds, so artifact and native-metadata tools are reported available without a target descriptor. ### Additional context Found while exercising typical REA workflows on macOS with `rea-agents@6.1.0`; each case was reproduced on the npm release and on a local build of `main`, and re-checked on `main` at 6a1e558db3ec2b69561e91ea817f1c2065dfc676 just before filing.

bsakaguchi

2026-10-15 18:24:50 +00:00