morluto/rea

Fork 0

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

[GH-ISSUE #8315] [Bug] Ghidra project edit refusal hides read-only mode behind generic target advice #6540

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

CLI; MCP or agent integration.

Observed behavior

Trying to annotate a caller-selected existing Ghidra project is correctly refused because REA opens that project mode read-only. The error headline and remediation instead say only “This analysis is unavailable for the current target. Choose another analysis or target.” The actual reason, Existing Ghidra project sessions are read-only., survives in details.reason.

Reproduction

On REA b43c329df779708e43ae297f498a844e45d9c923, Ghidra 12.1.4 and a self-owned arm64 Mach-O, select a matching existing project via REA_GHIDRA_PROJECT_PATH and REA_GHIDRA_PROGRAM_NAME.

MCP: open_binary, then binary_session({detail:"complete"}) correctly lists annotate_native_function, set_address_name, and set_addresses_names as unavailable with remediation Existing Ghidra project sessions are read-only. Calling annotate_native_function returns capability_unavailable with the generic headline/remediation above and the specific reason in details.reason.
CLI: rea annotate-native-function <target> audit_checkpoint_evaluate --comment 'not applied' --provider ghidra --format json exits 1 with the same generic message and specific nested reason. rea decompile and rea inspect-native-api on the selected project succeeded; their normalized values matched the MCP results. The target and selected project regular-file hashes stayed unchanged during the tested CLI/MCP sessions, and the target was not executed.

The selected-project refusal was observed on two owned project variants through MCP and once through CLI. No autonomous-agent behavior was measured.

Expected behavior

Preserve the read-only restriction and put the actual reason in the primary error/recovery. If explaining fresh-import mode as an option, make it explicit that it is a different ephemeral analysis chosen by the caller, not an automatic replacement for the selected project's work. Do not suggest another target as a remedy for a project-mode restriction or write to the source project.

Impact and scope

The correct reason is available in details and proactive binary_session discovery, so this is confusing recovery, not loss of the diagnosis or an unauthorized edit. Generic advice does not identify why the chosen project cannot be edited. Other capability failures and platforms were not tested.

REA version

Source b43c329df779708e43ae297f498a844e45d9c923; relevant Ghidra bridge/provider and CLI files unchanged at checked origin/main 23de10bb2849cdce8ddbe70504aa7cc57de75a98.

Runtime and platform

Node 24.22.1; macOS arm64; Ghidra 12.1.4; JDK 21.

Target and artifact context

Self-owned Mach-O executable and two owned project copies. No target execution. REA sessions left target/project file hashes unchanged.

Interface

CLI and MCP.

Earliest failure stage

Transport or result projection.

Relevant output or evidence

code: capability_unavailable, message and remediation.action: This analysis is unavailable for the current target. Choose another analysis or target. details.reason: Existing Ghidra project sessions are read-only.

Typed outcome or recovery expected

A provider-mode-aware reason and actionable, non-destructive recovery in both adapters, retaining the current capability code and refusal unless a separate design changes them.

Analysis or suspected cause

Source-derived: Ghidra capability projection supplies the specific reason; the common capability error presentation supplies generic guidance. Determine the correct owning boundary for preserving mode-specific recovery rather than parsing arbitrary text.

Additional context

Related #8165 discusses a separate checkpoint design; #3751 covers project loading; #8314 covers local-variable observations. Last known good error wording: NOT_ENOUGH_INFO.

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8315 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area CLI; MCP or agent integration. ### Observed behavior Trying to annotate a caller-selected existing Ghidra project is correctly refused because REA opens that project mode read-only. The error headline and remediation instead say only “This analysis is unavailable for the current target. Choose another analysis or target.” The actual reason, `Existing Ghidra project sessions are read-only.`, survives in `details.reason`. ### Reproduction On REA `b43c329df779708e43ae297f498a844e45d9c923`, Ghidra 12.1.4 and a self-owned arm64 Mach-O, select a matching existing project via `REA_GHIDRA_PROJECT_PATH` and `REA_GHIDRA_PROGRAM_NAME`. - MCP: `open_binary`, then `binary_session({detail:"complete"})` correctly lists `annotate_native_function`, `set_address_name`, and `set_addresses_names` as unavailable with remediation `Existing Ghidra project sessions are read-only.` Calling `annotate_native_function` returns `capability_unavailable` with the generic headline/remediation above and the specific reason in `details.reason`. - CLI: `rea annotate-native-function <target> audit_checkpoint_evaluate --comment 'not applied' --provider ghidra --format json` exits 1 with the same generic message and specific nested reason. `rea decompile` and `rea inspect-native-api` on the selected project succeeded; their normalized values matched the MCP results. The target and selected project regular-file hashes stayed unchanged during the tested CLI/MCP sessions, and the target was not executed. The selected-project refusal was observed on two owned project variants through MCP and once through CLI. No autonomous-agent behavior was measured. ### Expected behavior Preserve the read-only restriction and put the actual reason in the primary error/recovery. If explaining fresh-import mode as an option, make it explicit that it is a different ephemeral analysis chosen by the caller, not an automatic replacement for the selected project's work. Do not suggest another target as a remedy for a project-mode restriction or write to the source project. ### Impact and scope The correct reason is available in details and proactive `binary_session` discovery, so this is confusing recovery, not loss of the diagnosis or an unauthorized edit. Generic advice does not identify why the chosen project cannot be edited. Other capability failures and platforms were not tested. ### REA version Source `b43c329df779708e43ae297f498a844e45d9c923`; relevant Ghidra bridge/provider and CLI files unchanged at checked `origin/main` `23de10bb2849cdce8ddbe70504aa7cc57de75a98`. ### Runtime and platform Node 24.22.1; macOS arm64; Ghidra 12.1.4; JDK 21. ### Target and artifact context Self-owned Mach-O executable and two owned project copies. No target execution. REA sessions left target/project file hashes unchanged. ### Interface CLI and MCP. ### Earliest failure stage Transport or result projection. ### Relevant output or evidence `code: capability_unavailable`, `message` and `remediation.action`: `This analysis is unavailable for the current target. Choose another analysis or target.` `details.reason`: `Existing Ghidra project sessions are read-only.` ### Typed outcome or recovery expected A provider-mode-aware reason and actionable, non-destructive recovery in both adapters, retaining the current capability code and refusal unless a separate design changes them. ### Analysis or suspected cause Source-derived: [Ghidra capability projection](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/ghidra/GhidraProviderCapabilities.ts#L250-L265) supplies the specific reason; the common capability error presentation supplies generic guidance. Determine the correct owning boundary for preserving mode-specific recovery rather than parsing arbitrary text. ### Additional context Related #8165 discusses a separate checkpoint design; #3751 covers project loading; #8314 covers local-variable observations. Last known good error wording: NOT_ENOUGH_INFO. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi added the

bug

triage

labels

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

bsakaguchi commented

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

Author

Owner

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

Project-mode transition control: in one real MCP connection, I opened the selected read-only Ghidra project, switched the same target explicitly to Kuna 1.986, and then explicitly switched back to Ghidra 12.1.4. binary_session correctly changed annotation availability from the Ghidra read-only reason, to Kuna's missing provider capability, and back to the Ghidra read-only reason. Both Ghidra annotation attempts were refused; the selected project's authored function name, parameter/local names and comment reappeared in identical pseudocode after reopening. The executable and nine selected-project regular-file hashes were unchanged.

In a separate fresh Ghidra import with the project settings unset, discovery marked annotation available; a session-only comment succeeded and appeared in pseudocode. Its original executable hash was unchanged. This control shows the difference between the selected project's persisted metadata and a separate ephemeral session on this fixture; it does not establish that REA can edit or save the selected project, or that session edits survive close. The generic refusal wording reported above was unchanged in the selected-project test.

@morluto commented on GitHub (Oct 31, 2026): Project-mode transition control: in one real MCP connection, I opened the selected read-only Ghidra project, switched the same target explicitly to Kuna 1.986, and then explicitly switched back to Ghidra 12.1.4. `binary_session` correctly changed annotation availability from the Ghidra read-only reason, to Kuna's missing provider capability, and back to the Ghidra read-only reason. Both Ghidra annotation attempts were refused; the selected project's authored function name, parameter/local names and comment reappeared in identical pseudocode after reopening. The executable and nine selected-project regular-file hashes were unchanged. In a separate fresh Ghidra import with the project settings unset, discovery marked annotation available; a session-only comment succeeded and appeared in pseudocode. Its original executable hash was unchanged. This control shows the difference between the selected project's persisted metadata and a separate ephemeral session on this fixture; it does not establish that REA can edit or save the selected project, or that session edits survive close. The generic refusal wording reported above was unchanged in the selected-project test.

bsakaguchi closed this issue

2026-11-04 12:09:25 +00:00

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

No description provided.

Rows
Columns