[GH-ISSUE #8580] fix(ghidra): explain read-only project annotation refusal #6659

Open
opened 2026-11-01 21:13:00 +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/8580

Before submitting

  • I searched open and closed issues for a related report.
  • This report contains no private target data or credentials.

Area

MCP or agent integration.

Observed behavior

For a read-only existing Ghidra project, annotate_native_function correctly returns capability_unavailable. The top-level message and remediation say only to choose another analysis or target. details.reason correctly says the existing-project session is read-only, but the recovery does not explain how that applies to the caller's selected project or that a fresh import would not preserve its saved annotations.

Reproduction

On macOS arm64 with Node 24.22.1, Ghidra 12.1.4 and JDK 21, create an owned root Ghidra project for a self-built Mach-O. Start REA stdio MCP with REA_GHIDRA_PROJECT_PATH and REA_GHIDRA_PROGRAM_NAME=workflow, open the same target with Ghidra, and call annotate_native_function({procedure:"evaluate",name:"forbidden_change"}). Both compact and full profiles return capability_unavailable, with details.reason: Existing Ghidra project sessions are read-only. The top-level message and action are This analysis is unavailable for the current target. Choose another analysis or target. The procedure inventory is unchanged after the refusal; closing succeeds and source project/target hashes are unchanged. The target was not executed.

The same root-project control on #8567 head 96ba4225 gave the same generic recovery; its undeclared-operation guidance addresses a different boundary. A separate temporary merge of #3817 showed the same behavior for a nested project, but current main already reproduces it at the root.

Expected behavior

Keep the refusal and make the known read-only policy actionable at the point of failure. Explain that another provider or a fresh Ghidra import is an explicit choice with different analysis/session state; do not imply that a new session can edit or persist the selected project's annotations, switch providers automatically, or claim saved annotations transfer. If no safe equivalent preserves the requested project state, say so.

Impact and scope

One owned project, one function and Ghidra 12.1.4 on macOS arm64; no model-choice, prevalence or cross-platform claim. The policy is working; this report concerns recovery and caller choice.

REA version

REA 85013da0c; main 46c13b998 differs only in an unrelated Electron change. Separate #8567 control at 96ba4225.

Runtime and platform

Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21.

Target and artifact context

Self-built unexecuted Mach-O; SHA-256 ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d. Ghidra project was owned and read through REA's copy-first path.

Interface

MCP compact and full profiles.

Earliest failure stage

Provider capability / composed annotation workflow.

Relevant output or evidence

Error code capability_unavailable; top-level message and action say to choose another analysis or target. The explicit existing-project read-only reason is retained in details.reason.

Typed outcome or recovery expected

Preserve the typed refusal and explain the actual policy and consequences using the owner of the capability decision. Check both root and nested projects, CLI and MCP, explicit provider refusal, and that no existing analysis or evidence is silently discarded.

Analysis or suspected cause

NOT_ENOUGH_INFO: the producing and projection boundaries need further inspection. The #8567 comparison shows its generic undeclared-operation path alone does not change this response.

Additional context

Related #8567, #3817 and #8344. No change to the project's read-only authority is proposed.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8580 ### Before submitting - [x] I searched open and closed issues for a related report. - [x] This report contains no private target data or credentials. ### Area MCP or agent integration. ### Observed behavior For a read-only existing Ghidra project, `annotate_native_function` correctly returns `capability_unavailable`. The top-level message and remediation say only to choose another analysis or target. `details.reason` correctly says the existing-project session is read-only, but the recovery does not explain how that applies to the caller's selected project or that a fresh import would not preserve its saved annotations. ### Reproduction On macOS arm64 with Node 24.22.1, Ghidra 12.1.4 and JDK 21, create an owned root Ghidra project for a self-built Mach-O. Start REA stdio MCP with `REA_GHIDRA_PROJECT_PATH` and `REA_GHIDRA_PROGRAM_NAME=workflow`, open the same target with Ghidra, and call `annotate_native_function({procedure:"evaluate",name:"forbidden_change"})`. Both compact and full profiles return `capability_unavailable`, with `details.reason: Existing Ghidra project sessions are read-only.` The top-level message and action are `This analysis is unavailable for the current target. Choose another analysis or target.` The procedure inventory is unchanged after the refusal; closing succeeds and source project/target hashes are unchanged. The target was not executed. The same root-project control on #8567 head `96ba4225` gave the same generic recovery; its undeclared-operation guidance addresses a different boundary. A separate temporary merge of #3817 showed the same behavior for a nested project, but current main already reproduces it at the root. ### Expected behavior Keep the refusal and make the known read-only policy actionable at the point of failure. Explain that another provider or a fresh Ghidra import is an explicit choice with different analysis/session state; do not imply that a new session can edit or persist the selected project's annotations, switch providers automatically, or claim saved annotations transfer. If no safe equivalent preserves the requested project state, say so. ### Impact and scope One owned project, one function and Ghidra 12.1.4 on macOS arm64; no model-choice, prevalence or cross-platform claim. The policy is working; this report concerns recovery and caller choice. ### REA version REA `85013da0c`; main `46c13b998` differs only in an unrelated Electron change. Separate #8567 control at `96ba4225`. ### Runtime and platform Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21. ### Target and artifact context Self-built unexecuted Mach-O; SHA-256 `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`. Ghidra project was owned and read through REA's copy-first path. ### Interface MCP compact and full profiles. ### Earliest failure stage Provider capability / composed annotation workflow. ### Relevant output or evidence Error code `capability_unavailable`; top-level message and action say to choose another analysis or target. The explicit existing-project read-only reason is retained in `details.reason`. ### Typed outcome or recovery expected Preserve the typed refusal and explain the actual policy and consequences using the owner of the capability decision. Check both root and nested projects, CLI and MCP, explicit provider refusal, and that no existing analysis or evidence is silently discarded. ### Analysis or suspected cause NOT_ENOUGH_INFO: the producing and projection boundaries need further inspection. The #8567 comparison shows its generic undeclared-operation path alone does not change this response. ### Additional context Related #8567, #3817 and #8344. No change to the project's read-only authority is proposed. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0
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#6659
No description provided.