morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8430] [Bug] Snapshot refusal does not identify which binding differs #6603

New issue

Closed

opened 2026-11-01 21:12:36 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-01 21:12:36 +00:00

Owner

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

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

A snapshot bound to a different target is safely refused, but the error labels the mismatch profile_mismatch and does not say which binding differed. An agent cannot tell from that response whether it selected the wrong binary, provider, or analysis profile.

Reproduction

With Ghidra 12.1.4 or Kuna 1.986, open an owned Mach-O, resolve a function and save an analysis snapshot.
Open the original target in a new MCP session. Make a separate, same-basename copy with one byte appended and attempt to open that copy with the saved snapshot.
Both providers return evidence_integrity_mismatch: Analysis snapshot profile_mismatch: target, provider, or analysis profile does not match the requested binary. details.reason repeats the same text; no differing binding or digest is reported.

The modified copy was confirmed to have a different SHA-256; the selected provider stayed the same. The refused open preserved the original active session and, in the Ghidra control, a session-only function rename. Following the existing recovery by opening the changed target without a snapshot and resolving the function succeeded. The original, changed copy and snapshot digests remained unchanged during REA work; neither executable was run.

Expected behavior

Keep the fail-closed refusal and active-session preservation, while reporting the known mismatch dimension and useful expected/actual binding facts when available. Target identity, provider and analysis-profile differences can coexist; do not invent a single reason or silently switch the target or snapshot. This would let the caller choose the original target if it selected the wrong file, or intentionally analyze the new one.

Impact and scope

Observed once per provider on an intentionally changed byte-identical baseline, using a static Mach-O. The generic recovery works if the caller intends to discard snapshot reuse for the changed target; other mismatch combinations, other hosts, GUI sessions and prevalence are unverified.

REA version

Draft #8426 stack 458674fba8bc5adc7873adb99b5256ed0e16fc30; no claim this draft introduced the behavior.

Runtime and platform

macOS arm64, Node 24.22.1, Ghidra 12.1.4/JDK 21 and Kuna 1.986; TypeScript SDK and production MCP server with in-memory transport.

Target and artifact context

Original SHA-256 ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d; changed copy created solely for the test.

Interface

MCP. CLI mismatch presentation was not checked in this reproduction.

Earliest failure stage

Snapshot binding validation during open_binary.

Relevant output or evidence

The refusal's suggested fresh-analysis path succeeded, and the prior target and live Ghidra rename remained usable before intentionally switching targets. The test used a new server in the same process, not a separate OS process.

Typed outcome or recovery expected

Preserve evidence_integrity_mismatch and the current safe refusal; distinguish confirmed target and profile mismatches in structured details without treating an unknown comparison as a match.

Analysis or suspected cause

Source-derived: BinarySessionOpen.validateSnapshot tests the combined snapshotMatchesBinding predicate and constructs one AnalysisSnapshotMismatchError for all failed binding comparisons. The same general error is used for a staged mismatch.

Additional context

Related #3751 discusses project selection and #5921 concerns session preservation for profileless snapshots; this report focuses on identifying the binding that actually failed.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8430 ### 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 Evidence, artifacts, or reconstruction ### Observed behavior A snapshot bound to a different target is safely refused, but the error labels the mismatch `profile_mismatch` and does not say which binding differed. An agent cannot tell from that response whether it selected the wrong binary, provider, or analysis profile. ### Reproduction 1. With Ghidra 12.1.4 or Kuna 1.986, open an owned Mach-O, resolve a function and save an analysis snapshot. 2. Open the original target in a new MCP session. Make a separate, same-basename copy with one byte appended and attempt to open that copy with the saved snapshot. 3. Both providers return `evidence_integrity_mismatch`: `Analysis snapshot profile_mismatch: target, provider, or analysis profile does not match the requested binary`. `details.reason` repeats the same text; no differing binding or digest is reported. The modified copy was confirmed to have a different SHA-256; the selected provider stayed the same. The refused open preserved the original active session and, in the Ghidra control, a session-only function rename. Following the existing recovery by opening the changed target without a snapshot and resolving the function succeeded. The original, changed copy and snapshot digests remained unchanged during REA work; neither executable was run. ### Expected behavior Keep the fail-closed refusal and active-session preservation, while reporting the known mismatch dimension and useful expected/actual binding facts when available. Target identity, provider and analysis-profile differences can coexist; do not invent a single reason or silently switch the target or snapshot. This would let the caller choose the original target if it selected the wrong file, or intentionally analyze the new one. ### Impact and scope Observed once per provider on an intentionally changed byte-identical baseline, using a static Mach-O. The generic recovery works if the caller intends to discard snapshot reuse for the changed target; other mismatch combinations, other hosts, GUI sessions and prevalence are unverified. ### REA version Draft #8426 stack `458674fba8bc5adc7873adb99b5256ed0e16fc30`; no claim this draft introduced the behavior. ### Runtime and platform macOS arm64, Node 24.22.1, Ghidra 12.1.4/JDK 21 and Kuna 1.986; TypeScript SDK and production MCP server with in-memory transport. ### Target and artifact context Original SHA-256 `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`; changed copy created solely for the test. ### Interface MCP. CLI mismatch presentation was not checked in this reproduction. ### Earliest failure stage Snapshot binding validation during `open_binary`. ### Relevant output or evidence The refusal's suggested fresh-analysis path succeeded, and the prior target and live Ghidra rename remained usable before intentionally switching targets. The test used a new server in the same process, not a separate OS process. ### Typed outcome or recovery expected Preserve `evidence_integrity_mismatch` and the current safe refusal; distinguish confirmed target and profile mismatches in structured details without treating an unknown comparison as a match. ### Analysis or suspected cause Source-derived: `BinarySessionOpen.validateSnapshot` tests the combined `snapshotMatchesBinding` predicate and constructs one `AnalysisSnapshotMismatchError` for all failed binding comparisons. The same general error is used for a staged mismatch. ### Additional context Related #3751 discusses project selection and #5921 concerns session preservation for profileless snapshots; this report focuses on identifying the binding that actually failed. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi

2026-11-01 21:12:36 +00:00

closed this issue
added the
bug

triage
labels

bsakaguchi commented

2026-11-01 21:12:36 +00:00

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

Draft #8432 implements a shared binding-mismatch projection for explicit and staged snapshots, active imports, and CLI target preflight. It reports saved vs selected target identities, provider identities and profile digests when those comparisons were made; a profile not yet compared remains explicit. The error code and fail-closed behavior remain.

Real Ghidra 12.1.4 and Kuna 1.986 MCP checks repeated the changed-target case: both now report the two digests, keep the original session usable, and permit the tested fresh-analysis recovery. The actual rea function --snapshot ... --format json CLI reported the target mismatch and explicitly noted that profile comparison had not run. The target and snapshot files remained unchanged during REA work; targets were not executed. The PR lists synthetic provider/profile/combined and profileless tests and the unverified real-provider cases.

@morluto commented on GitHub (Nov 1, 2026): Draft #8432 implements a shared binding-mismatch projection for explicit and staged snapshots, active imports, and CLI target preflight. It reports saved vs selected target identities, provider identities and profile digests when those comparisons were made; a profile not yet compared remains explicit. The error code and fail-closed behavior remain. Real Ghidra 12.1.4 and Kuna 1.986 MCP checks repeated the changed-target case: both now report the two digests, keep the original session usable, and permit the tested fresh-analysis recovery. The actual `rea function --snapshot ... --format json` CLI reported the target mismatch and explicitly noted that profile comparison had not run. The target and snapshot files remained unchanged during REA work; targets were not executed. The PR lists synthetic provider/profile/combined and profileless tests and the unverified real-provider cases.

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

No description provided.

Rows
Columns