morluto/rea

Fork 0

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

[GH-ISSUE #8242] [Docs] Explain Ghidra CLI annotation lifetime in command help #6508

New issue

Open

opened 2026-11-01 21:11:46 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-11-01 21:11:46 +00:00

Owner

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

Before submitting

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

Documentation location

rea annotate-native-function --help, generated from registerAnnotationCommand.

Problem

The command help says “Edit function annotations and return refreshed analysis” but does not mention that, with a fresh Ghidra CLI session, the edit is discarded when the command finishes. A caller reading only help can expect the new name to be available to a subsequent CLI command. The returned Evidence does explicitly state the ephemeral lifetime, and the authored REA skill describes it; this report concerns discoverability before invocation, not a claim that the behavior is undocumented everywhere.

Expected content

Briefly state the Ghidra CLI edit lifetime in the command's own help and indicate that the returned dossier is the edited observation. Point to the existing session-oriented MCP workflow for multiple dependent edits or reads, and to documented project/checkpoint limitations where useful. Do not imply that MCP keeps edits after close or that existing-project mode permits mutation.

Supporting evidence

On macOS arm64, Node 24.22.1 and Ghidra 12.1.4 at REA 53a4ab78451a0654e9c3beb3d43a5e371a288fcc, I ran rea annotate-native-function <owned-mach-o> _adjust --name cli_audit_adjust --comment 'CLI ephemeral annotation' --provider ghidra --format json. It exited 0; the returned annotations and dossier carried the new name/comment and its limitations correctly said the CLI session is discarded.

A separate rea function <same-path> cli_audit_adjust --provider ghidra --format json exited 1 with an unknown-procedure issue and generic schema advice. A third invocation using the original _adjust succeeded. The target SHA-256 stayed unchanged; it was not executed. This is one real Ghidra CLI sequence and does not establish behavior for Hopper or IDA.

Additional context

REA native skill already describes the Ghidra CLI and MCP lifetimes. Related #6405 covers persistent annotation replay and #8165 covers durable program checkpoints; this request does not propose either capability. No autonomous-agent success rate was measured.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8242 ### Before submitting - [x] I searched the existing issues for a related documentation report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location `rea annotate-native-function --help`, generated from [`registerAnnotationCommand`](https://github.com/morluto/rea/blob/53a4ab78451a0654e9c3beb3d43a5e371a288fcc/src/cli/coreNativeCommands.ts#L464-L493). ### Problem The command help says “Edit function annotations and return refreshed analysis” but does not mention that, with a fresh Ghidra CLI session, the edit is discarded when the command finishes. A caller reading only help can expect the new name to be available to a subsequent CLI command. The returned Evidence **does** explicitly state the ephemeral lifetime, and the authored REA skill describes it; this report concerns discoverability before invocation, not a claim that the behavior is undocumented everywhere. ### Expected content Briefly state the Ghidra CLI edit lifetime in the command's own help and indicate that the returned dossier is the edited observation. Point to the existing session-oriented MCP workflow for multiple dependent edits or reads, and to documented project/checkpoint limitations where useful. Do not imply that MCP keeps edits after close or that existing-project mode permits mutation. ### Supporting evidence On macOS arm64, Node 24.22.1 and Ghidra 12.1.4 at REA `53a4ab78451a0654e9c3beb3d43a5e371a288fcc`, I ran `rea annotate-native-function <owned-mach-o> _adjust --name cli_audit_adjust --comment 'CLI ephemeral annotation' --provider ghidra --format json`. It exited 0; the returned annotations and dossier carried the new name/comment and its limitations correctly said the CLI session is discarded. A separate `rea function <same-path> cli_audit_adjust --provider ghidra --format json` exited 1 with an unknown-procedure issue and generic schema advice. A third invocation using the original `_adjust` succeeded. The target SHA-256 stayed unchanged; it was not executed. This is one real Ghidra CLI sequence and does not establish behavior for Hopper or IDA. ### Additional context [REA native skill](https://github.com/morluto/rea/blob/53a4ab78451a0654e9c3beb3d43a5e371a288fcc/.agents/skills/reverse-engineer-anything/references/native-and-artifacts.md) already describes the Ghidra CLI and MCP lifetimes. Related #6405 covers persistent annotation replay and #8165 covers durable program checkpoints; this request does not propose either capability. No autonomous-agent success rate was measured.

bsakaguchi added the

documentation

triage

labels

2026-11-01 21:11:46 +00:00

bsakaguchi commented

2026-11-01 21:11:47 +00:00

Author

Owner

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

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:47 +00:00

Author

Owner

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

Can I take this? I have some time to work on it this week.

@MannXo commented on GitHub (Oct 31, 2026): Can I take this? I have some time to work on it this week.

bsakaguchi commented

2026-11-01 21:11:47 +00:00

Author

Owner

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

Checked the rendered help from exact PR #8271 head 9a89d61818988d78657d9c5e55050eb0169f9e8e after building it. It states that Ghidra CLI edits are discarded on exit, that the returned dossier is the edited observation, and that dependent MCP edits and reads last until close.

A separate real Ghidra 12.1.4 control on main e6d061897 supports that wording on one macOS arm64 fixture. The CLI annotation JSON contained the edited name, comment and pseudocode; a new CLI invocation could not resolve that name but could resolve the original. In MCP, a rename and comment were visible in a subsequent same-session pseudocode call; after close_binary and reopening the target, the edited name was unavailable and the original worked. The target digest was unchanged.

This tests the behavior on main and the help output on the PR head; it is not a separate real-provider run of the documentation-only PR, or evidence for other providers or project modes. A separate saved-Evidence view limitation is recorded on #8243.

@morluto commented on GitHub (Oct 31, 2026): Checked the rendered help from exact [PR #8271](https://github.com/morluto/rea/pull/8271) head `9a89d61818988d78657d9c5e55050eb0169f9e8e` after building it. It states that Ghidra CLI edits are discarded on exit, that the returned dossier is the edited observation, and that dependent MCP edits and reads last until close. A separate real Ghidra 12.1.4 control on main `e6d061897` supports that wording on one macOS arm64 fixture. The CLI annotation JSON contained the edited name, comment and pseudocode; a new CLI invocation could not resolve that name but could resolve the original. In MCP, a rename and comment were visible in a subsequent same-session pseudocode call; after `close_binary` and reopening the target, the edited name was unavailable and the original worked. The target digest was unchanged. This tests the behavior on main and the help output on the PR head; it is not a separate real-provider run of the documentation-only PR, or evidence for other providers or project modes. A separate saved-Evidence view limitation is recorded on [#8243](https://github.com/morluto/rea/issues/8243#issuecomment-6540861060).

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

No description provided.

Rows
Columns