morluto/rea

Fork 0

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

[GH-ISSUE #8208] [Design] Make missing-function recovery aware of selected Ghidra projects #6484

New issue

Open

opened 2026-11-01 21:11:32 +00:00 by bsakaguchi · 8 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched open and closed issues and pull requests for a related discussion. #8169 covers project/target identity mismatch; #8165 covers checkpoint persistence and editability.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

When a valid function selector is absent from a caller-selected existing Ghidra project, can REA give an agent a scoped recovery path that preserves the project's unknown analysis completeness and the caller's project choice?

Context and evidence

On macOS arm64/Ghidra 12.1.4, I imported a self-owned Mach-O into a new project with analyzeHeadless -noanalysis and saved it. In a real REA MCP session selecting that project and the matching original binary:

binary_session and list_procedures explicitly stated that the copied project is opened without auto-analysis and that its original analysis completeness and settings are unknown. The inventory contained only entry.
procedure_pseudo_code({"procedure":"_evaluate"}) returned invalid_request; the detailed issue said Unknown Ghidra procedure name or address: _evaluate, but generic remediation told the caller to read the input schema or refresh the tool catalog. The supplied selector was syntactically valid.
In a separate fresh-import REA/Ghidra session on the exact same binary, list_procedures included _evaluate and pseudocode succeeded. That fresh import is a comparison, not a safe automatic replacement for the selected project: a project may contain valuable caller annotations or other analysis.

The deliberately unanalysed project is known to the experimenter; REA correctly does not claim that arbitrary existing projects are incomplete. The target was not executed or changed. This is one project/target case and not a measurement of agent failure.

Selected-project recovery control

On PR #8470 head 3dc41af77, Ghidra 12.1.4/JDK 21 and macOS arm64, I selected a disposable project containing an intentional prior program-memory edit. In both compact and full stdio MCP profiles, procedure_assembly at an unlisted address reported the missing entry, stated that the selected project's analysis completeness is unknown, and described fresh import as an explicit separate process that would omit its annotations. In the same session after the refusal, read_bytes at the edited function returned 40058052c0035fd6 and procedure_pseudo_code returned 0x2a; the admitted original file contains 00008052c0035fd6 at the corresponding offset. This confirms the session continued to serve the selected project's edited state in this fixture, rather than silently replacing it with a fresh import. Every target and original project file hash was unchanged after both sessions. The fixture was not executed. This does not establish behavior for other project histories or prove the memory edit was an annotation.

Expected interaction with targets

Read selected local files and a copied analysis project; launch the selected static provider. Do not write or reanalyze the original project.

Boundary details (optional)

A missing selector may arise from a typo, alias, unsupported name, incomplete analysis, or genuine absence. Do not diagnose the reason without evidence or treat an unknown project history as absent/completed. Do not silently replace the user's selected project with a fresh import or discard its edits.

Options and tradeoffs

Consider a conditional recovery hint to list currently discovered procedures and inspect the selected session's analysis-history limitation; separately explain that a fresh import requires an explicit user choice/reconfiguration. Compare that with a more precise typed not-found result. Preserve exact selector, target/project identity, existing project read-only behavior, and normal invalid-input validation.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise analysed, deliberately unanalysed, annotated, genuinely missing and ambiguous-name projects; verify the errors and recovery do not claim completeness or change provider/project selection. Cover CLI/MCP and session preservation.

References

Related: #8165 and #8169. REA d48e472fa plus unrelated Kuna 1.986 baseline changes in #8187.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8208 ### Before submitting - [x] I searched open and closed issues and pull requests for a related discussion. #8169 covers project/target identity mismatch; #8165 covers checkpoint persistence and editability. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed When a valid function selector is absent from a caller-selected existing Ghidra project, can REA give an agent a scoped recovery path that preserves the project's unknown analysis completeness and the caller's project choice? ### Context and evidence On macOS arm64/Ghidra 12.1.4, I imported a self-owned Mach-O into a new project with `analyzeHeadless -noanalysis` and saved it. In a real REA MCP session selecting that project and the matching original binary: - `binary_session` and `list_procedures` explicitly stated that the copied project is opened without auto-analysis and that its original analysis completeness and settings are unknown. The inventory contained only `entry`. - `procedure_pseudo_code({"procedure":"_evaluate"})` returned `invalid_request`; the detailed issue said `Unknown Ghidra procedure name or address: _evaluate`, but generic remediation told the caller to read the input schema or refresh the tool catalog. The supplied selector was syntactically valid. - In a separate fresh-import REA/Ghidra session on the exact same binary, `list_procedures` included `_evaluate` and pseudocode succeeded. That fresh import is a comparison, not a safe automatic replacement for the selected project: a project may contain valuable caller annotations or other analysis. The deliberately unanalysed project is known to the experimenter; REA correctly does not claim that arbitrary existing projects are incomplete. The target was not executed or changed. This is one project/target case and not a measurement of agent failure. ### Selected-project recovery control On PR #8470 head `3dc41af77`, Ghidra 12.1.4/JDK 21 and macOS arm64, I selected a disposable project containing an intentional prior program-memory edit. In both compact and full stdio MCP profiles, `procedure_assembly` at an unlisted address reported the missing entry, stated that the selected project's analysis completeness is unknown, and described fresh import as an explicit separate process that would omit its annotations. In the same session after the refusal, `read_bytes` at the edited function returned `40058052c0035fd6` and `procedure_pseudo_code` returned `0x2a`; the admitted original file contains `00008052c0035fd6` at the corresponding offset. This confirms the session continued to serve the selected project's edited state in this fixture, rather than silently replacing it with a fresh import. Every target and original project file hash was unchanged after both sessions. The fixture was not executed. This does not establish behavior for other project histories or prove the memory edit was an annotation. ### Expected interaction with targets Read selected local files and a copied analysis project; launch the selected static provider. Do not write or reanalyze the original project. ### Boundary details (optional) A missing selector may arise from a typo, alias, unsupported name, incomplete analysis, or genuine absence. Do not diagnose the reason without evidence or treat an unknown project history as absent/completed. Do not silently replace the user's selected project with a fresh import or discard its edits. ### Options and tradeoffs Consider a conditional recovery hint to list currently discovered procedures and inspect the selected session's analysis-history limitation; separately explain that a fresh import requires an explicit user choice/reconfiguration. Compare that with a more precise typed not-found result. Preserve exact selector, target/project identity, existing project read-only behavior, and normal invalid-input validation. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise analysed, deliberately unanalysed, annotated, genuinely missing and ambiguous-name projects; verify the errors and recovery do not claim completeness or change provider/project selection. Cover CLI/MCP and session preservation. ### References Related: #8165 and #8169. REA `d48e472fa` plus unrelated Kuna 1.986 baseline changes in #8187. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

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

Author

Owner

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

A control with a fully analyzed, explicitly selected project program shows that a missing selector does not imply incomplete project analysis. One owned Ghidra project contained two root programs imported from byte-identical Mach-O files; direct headless scripts gave their same function different names, selected_alpha and selected_beta. In a real REA/Ghidra MCP session selecting program_beta, procedure_pseudo_code({procedure:"selected_beta"}) succeeded. Asking for selected_alpha returned invalid_request with Unknown Ghidra procedure name or address in details and generic schema-refresh remediation. The selected beta program was valid and analyzed; the other name belonged to a different program in the same project.

This reinforces a narrow recovery hint to inspect the current selected project's observed inventory and binding, rather than diagnosing incomplete analysis or searching/switching to another program automatically. No GUI or target execution was involved. Missing project-program selection itself is distinct and tracked by #8216.

@morluto commented on GitHub (Oct 30, 2026): A control with a fully analyzed, explicitly selected project program shows that a missing selector does not imply incomplete project analysis. One owned Ghidra project contained two root programs imported from byte-identical Mach-O files; direct headless scripts gave their same function different names, `selected_alpha` and `selected_beta`. In a real REA/Ghidra MCP session selecting `program_beta`, `procedure_pseudo_code({procedure:"selected_beta"})` succeeded. Asking for `selected_alpha` returned `invalid_request` with `Unknown Ghidra procedure name or address` in details and generic schema-refresh remediation. The selected beta program was valid and analyzed; the other name belonged to a different program in the same project. This reinforces a narrow recovery hint to inspect the current selected project's observed inventory and binding, rather than diagnosing incomplete analysis or searching/switching to another program automatically. No GUI or target execution was involved. Missing project-program selection itself is distinct and tracked by #8216.

bsakaguchi commented

2026-11-01 21:11:33 +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:33 +00:00

Author

Owner

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

Existing search-summary recovery

At REA b43c329df779708e43ae297f498a844e45d9c923, real stdio MCP search_procedures({pattern:"evaluate",detail:"summary"}) on the same source-owned Mach-O returned one retained row after fresh Ghidra 12.1.4 analysis, but zero in the deliberately -noanalysis selected project. Both summaries reported discovery_coverage: "unknown"; the selected project's page was exhausted within its zero-row retained view, and explicitly warned that missing matches do not establish absence outside the observation. Kuna 1.986 likewise reported unknown discovery, and returned the known global_count data label as a procedure candidate (#8168).

The CLI rea search <target> evaluate --kind procedures --provider ghidra --format json --full-output on the selected project returned the same empty complete Evidence as MCP, including the prior-analysis-unknown limitation. The CLI search command does not advertise a summary option, but passing that complete Evidence inline to rea inspect-analysis-view with view:{kind:"summary"} successfully produced the same zero rows and structured discovery_coverage: "unknown" without reopening the target. This is an existing, explicit two-step route, not an autonomous-agent selection test or evidence that a missing function is absent.

The target and ten selected-project file hashes were unchanged; the binary was not executed. This control may help scope recovery improvements without discarding the selected project or duplicating the existing inventory view. Related count-scope discussion: #8287.

@morluto commented on GitHub (Oct 31, 2026): ### Existing search-summary recovery At REA `b43c329df779708e43ae297f498a844e45d9c923`, real stdio MCP `search_procedures({pattern:"evaluate",detail:"summary"})` on the same source-owned Mach-O returned one retained row after fresh Ghidra 12.1.4 analysis, but zero in the deliberately `-noanalysis` selected project. Both summaries reported `discovery_coverage: "unknown"`; the selected project's page was exhausted **within its zero-row retained view**, and explicitly warned that missing matches do not establish absence outside the observation. Kuna 1.986 likewise reported unknown discovery, and returned the known `global_count` data label as a procedure candidate (#8168). The CLI `rea search <target> evaluate --kind procedures --provider ghidra --format json --full-output` on the selected project returned the same empty complete Evidence as MCP, including the prior-analysis-unknown limitation. The CLI search command does not advertise a summary option, but passing that complete Evidence inline to `rea inspect-analysis-view` with `view:{kind:"summary"}` successfully produced the same zero rows and structured `discovery_coverage: "unknown"` without reopening the target. This is an existing, explicit two-step route, not an autonomous-agent selection test or evidence that a missing function is absent. The target and ten selected-project file hashes were unchanged; the binary was not executed. This control may help scope recovery improvements without discarding the selected project or duplicating the existing inventory view. Related count-scope discussion: #8287.

bsakaguchi commented

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

Author

Owner

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

Additional real MCP workflow comparison on the same unexecuted arm64 Mach-O used in the earlier selected-project test (Ghidra 12.1.4): trace_feature({query:"evaluate"}) on a fresh import returned the _evaluate procedure at 0x100000430 and a source reference at 0x1000004b0; the caller-selected project imported with -noanalysis returned two string matches but no matching procedure or procedure reference. Both returned truncated:false and residual_unknowns:[]. The selected project's Evidence did explicitly state that the original analysis completeness and settings are unknown; this is not a claim that truncated promises complete provider discovery.

This demonstrates that the recovery/discovery question also affects a composed agent task, not just direct function search. Target and all 10 recorded original project files had unchanged hashes. The Ghidra results are observed inventories, not proof of all possible functions or references.

For maintainer visibility: @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

@morluto commented on GitHub (Oct 31, 2026): Additional real MCP workflow comparison on the same unexecuted arm64 Mach-O used in the earlier selected-project test (Ghidra 12.1.4): `trace_feature({query:"evaluate"})` on a fresh import returned the `_evaluate` procedure at `0x100000430` and a source reference at `0x1000004b0`; the caller-selected project imported with `-noanalysis` returned two string matches but no matching procedure or procedure reference. Both returned `truncated:false` and `residual_unknowns:[]`. The selected project's Evidence did explicitly state that the original analysis completeness and settings are unknown; this is not a claim that `truncated` promises complete provider discovery. This demonstrates that the recovery/discovery question also affects a composed agent task, not just direct function search. Target and all 10 recorded original project files had unchanged hashes. The Ghidra results are observed inventories, not proof of all possible functions or references. For maintainer visibility: @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi commented

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

Author

Owner

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

Ambiguous-name recovery control in a fresh Ghidra session

The issue asks for ambiguous-name coverage. In a separate fresh-import, real Ghidra 12.1.4 session on REA b43c329df779708e43ae297f498a844e45d9c923, an arm64 Mach-O with audit_over(int) and audit_over(long) produced two distinct audit_over procedure entries. MCP find_xrefs_to_name({name:"audit_over"}) correctly refused to select either and preserved both candidate addresses in details.issues. Its headline nevertheless said Analysis input is invalid, and remediation and machine-readable recovery directed the caller to inspect the input schema.

The real CLI rea xrefs <fixture> audit_over --provider ghidra --format json likewise exited 1 with schema-repair remediation. Its nested issue gave the actionable reason: the name was ambiguous at 0x1000003f8 and 0x100000408, and the caller should select an exact address. The same CLI command with 0x1000003f8 succeeded; MCP xrefs for each exact address found its respective call site. The target was not executed and its SHA-256 remained unchanged. This is an ambiguity-recovery control, not a claim about an existing project's analysis completeness or observed agent behavior.

Source-derived: the shared xref resolver constructs an AnalysisInputError with the useful explanation in an issue, while the default input-error presentation supplies schema-repair guidance when no specific remediation is present. This parallels, but is a different cause of, the unbacked-address recovery in #8244. A scoped improvement should retain actual schema-validation guidance while offering selection of an observed candidate for ambiguity; it must not infer a unique answer or replace a selected project.

@morluto commented on GitHub (Oct 31, 2026): ### Ambiguous-name recovery control in a fresh Ghidra session The issue asks for ambiguous-name coverage. In a separate **fresh-import**, real Ghidra 12.1.4 session on REA `b43c329df779708e43ae297f498a844e45d9c923`, an arm64 Mach-O with `audit_over(int)` and `audit_over(long)` produced two distinct `audit_over` procedure entries. MCP `find_xrefs_to_name({name:"audit_over"})` correctly refused to select either and preserved both candidate addresses in `details.issues`. Its headline nevertheless said `Analysis input is invalid`, and remediation and machine-readable recovery directed the caller to inspect the input schema. The real CLI `rea xrefs <fixture> audit_over --provider ghidra --format json` likewise exited 1 with schema-repair remediation. Its nested issue gave the actionable reason: the name was ambiguous at `0x1000003f8` and `0x100000408`, and the caller should select an exact address. The same CLI command with `0x1000003f8` succeeded; MCP xrefs for each exact address found its respective call site. The target was not executed and its SHA-256 remained unchanged. This is an ambiguity-recovery control, not a claim about an existing project's analysis completeness or observed agent behavior. Source-derived: the [shared xref resolver](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/application/XrefsAddressResolution.ts#L95-L110) constructs an `AnalysisInputError` with the useful explanation in an issue, while the [default input-error presentation](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/domain/analysisErrorPresentation.ts#L199-L205) supplies schema-repair guidance when no specific remediation is present. This parallels, but is a different cause of, the unbacked-address recovery in #8244. A scoped improvement should retain actual schema-validation guidance while offering selection of an observed candidate for ambiguity; it must not infer a unique answer or replace a selected project.

bsakaguchi commented

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

Author

Owner

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

Existing comparison workflow: selected project versus fresh analysis

On REA a989c0e with real Ghidra 12.1.4, I collected separate list_procedures Evidence for the same source-owned Mach-O under a fresh import (three entries) and a caller-selected -noanalysis project (one entry). I exported each bundle, imported both in a fresh target-free MCP server, and ran match_native_functions in both directions.

The matcher paired the shared entry by exact symbol and reported the other two functions only on the fresh side. Crucially it labeled the scope provider-observed-inputs, marked source coverage partial and both inventory-completeness values unknown, and included the selected-project/no-auto-analysis limitation. Reversing inputs reversed the unmatched side. A fresh-versus-itself control matched all three and used complete-within-inputs while still marking both inventory completeness values unknown. These results correctly describe the supplied observations; the unmatched rows do not establish added/removed artifact functions.

The offline CLI match-native-functions, given both Evidence bundles via the documented --source_bundle options, returned the same normalized result as MCP. This supports reusing the existing comparison and Evidence boundaries when evaluating recovery, while keeping the caller's selected project and incomplete analysis explicit. The fixture target and all original selected-project regular-file hashes remained unchanged during collection; the target was not executed. One project and provider version do not establish general comparison correctness.

@morluto commented on GitHub (Oct 31, 2026): ### Existing comparison workflow: selected project versus fresh analysis On REA `a989c0e` with real Ghidra 12.1.4, I collected separate `list_procedures` Evidence for the **same** source-owned Mach-O under a fresh import (three entries) and a caller-selected `-noanalysis` project (one entry). I exported each bundle, imported both in a fresh target-free MCP server, and ran `match_native_functions` in both directions. The matcher paired the shared `entry` by exact symbol and reported the other two functions only on the fresh side. Crucially it labeled the scope `provider-observed-inputs`, marked source coverage `partial` and both inventory-completeness values `unknown`, and included the selected-project/no-auto-analysis limitation. Reversing inputs reversed the unmatched side. A fresh-versus-itself control matched all three and used `complete-within-inputs` while still marking both inventory completeness values unknown. These results correctly describe the supplied observations; the unmatched rows do not establish added/removed artifact functions. The offline CLI `match-native-functions`, given both Evidence bundles via the documented `--source_bundle` options, returned the same normalized result as MCP. This supports reusing the existing comparison and Evidence boundaries when evaluating recovery, while keeping the caller's selected project and incomplete analysis explicit. The fixture target and all original selected-project regular-file hashes remained unchanged during collection; the target was not executed. One project and provider version do not establish general comparison correctness.

bsakaguchi commented

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

Author

Owner

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

Missing-name control across fresh and selected projects

On clean main 6e9ee97a, real Ghidra 12.1.4 and SDK 2.3.1 MCP on macOS arm64, I requested an invented, syntactically valid procedure name with procedure_address against both a fresh import and the deliberately unanalyzed selected project. Both compact and full profiles returned invalid_request with the unknown-name detail and inspect_input_contract recovery. The operation remained advertised available; list_procedures succeeded afterward in each session.

For this fixture the fresh inventory contained three procedures, and the selected-project inventory contained one and retained the unknown original analysis-history limitation. The invented name was absent in both inventories; this does not prove absence from arbitrary target code. The fresh case shows that schema-directed recovery is also misleading for a valid missing selector outside selected projects, while the selected-project caveat remains distinct. Original target and project hashes were unchanged, and successful calls were validated against the fetched SDK schemas. No broader name-resolution or host claim.

@morluto commented on GitHub (Nov 1, 2026): ### Missing-name control across fresh and selected projects On clean main `6e9ee97a`, real Ghidra 12.1.4 and SDK 2.3.1 MCP on macOS arm64, I requested an invented, syntactically valid procedure name with `procedure_address` against both a fresh import and the deliberately unanalyzed selected project. Both compact and full profiles returned `invalid_request` with the unknown-name detail and `inspect_input_contract` recovery. The operation remained advertised available; `list_procedures` succeeded afterward in each session. For this fixture the fresh inventory contained three procedures, and the selected-project inventory contained one and retained the unknown original analysis-history limitation. The invented name was absent in both inventories; this does not prove absence from arbitrary target code. The fresh case shows that schema-directed recovery is also misleading for a valid missing selector outside selected projects, while the selected-project caveat remains distinct. Original target and project hashes were unchanged, and successful calls were validated against the fetched SDK schemas. No broader name-resolution or host claim.

bsakaguchi commented

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

Author

Owner

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

Opened draft #8470 for the missing-selector recovery. The Ghidra bridge now distinguishes a procedure lookup miss from other not_found responses, and the shared CLI/MCP projection reports the exact selector, current-inventory search and the fact that an absent entry does not prove artifact absence. Only a selected existing project receives the additional option to explicitly start a fresh import, with a warning that its annotations will not carry over. It never changes the selected project automatically.

Real Ghidra 12.1.4 on macOS arm64: a deliberately unanalyzed selected project and a separate fresh import exercised full/compact stdio MCP and the actual CLI. The selected project remained usable after refusal; the same target's fresh CLI procedure search found _evaluate. Both target and original project hashes remained unchanged. Additional controls covered multiple procedure operations, a missing analysis address, the numeric file-offset fallback, and an ambiguous overload followed by an exact address. A follow-up also improves ambiguity recovery, as described below. The PR includes scope and test limitations; human author-readiness remains unchecked.

Follow-up: a valid explicit file-offset:0x430 (and bare numeric 0x430) mapped to an address in the selected project that had no function. The first PR version still gave schema advice there. The updated PR now preserves the mapped address and gives the same lookup recovery; both forms passed real Ghidra controls. The real-Ghidra verifier's new bridge checks for a missing name and a mapped initialized-data offset completed, but the overall host verifier later failed at the existing #8172 MCP 1,024-element input limit; it did not pass as a whole.

The same public workflow also showed a distinct valid-offset case: file-offset:0xdeadbeef had no loaded source mapping, but its specific Ghidra explanation was hidden behind schema advice. The PR now preserves that outcome separately and recommends inspecting load-image mappings. Both explicit and bare-offset forms passed real Ghidra stdio MCP in fresh and selected sessions, both schema profiles; the CLI --file-offset path also returned the mapping guidance. This does not settle the selector-design question in #8178 or change project selection.

Follow-up: real Ghidra reproduced generic schema-repair advice for an overloaded name and for a file offset mapped to two loaded addresses. The PR now preserves both candidate lists, distinguishes these two producer outcomes, and asks the caller to choose an explicit address. Both candidates succeeded in real full/compact MCP sessions and both outcomes were exercised through the CLI; the targets and selected project were unchanged. This is a controlled fixture on one host, not an autonomous-agent or broad project study.

@morluto commented on GitHub (Nov 1, 2026): Opened draft #8470 for the missing-selector recovery. The Ghidra bridge now distinguishes a procedure lookup miss from other `not_found` responses, and the shared CLI/MCP projection reports the exact selector, current-inventory search and the fact that an absent entry does not prove artifact absence. Only a selected existing project receives the additional option to explicitly start a fresh import, with a warning that its annotations will not carry over. It never changes the selected project automatically. Real Ghidra 12.1.4 on macOS arm64: a deliberately unanalyzed selected project and a separate fresh import exercised full/compact stdio MCP and the actual CLI. The selected project remained usable after refusal; the same target's fresh CLI procedure search found `_evaluate`. Both target and original project hashes remained unchanged. Additional controls covered multiple procedure operations, a missing analysis address, the numeric file-offset fallback, and an ambiguous overload followed by an exact address. A follow-up also improves ambiguity recovery, as described below. The PR includes scope and test limitations; human author-readiness remains unchecked. Follow-up: a valid explicit `file-offset:0x430` (and bare numeric `0x430`) mapped to an address in the selected project that had no function. The first PR version still gave schema advice there. The updated PR now preserves the mapped address and gives the same lookup recovery; both forms passed real Ghidra controls. The real-Ghidra verifier's new bridge checks for a missing name and a mapped initialized-data offset completed, but the overall host verifier later failed at the existing #8172 MCP 1,024-element input limit; it did not pass as a whole. The same public workflow also showed a distinct valid-offset case: `file-offset:0xdeadbeef` had no loaded source mapping, but its specific Ghidra explanation was hidden behind schema advice. The PR now preserves that outcome separately and recommends inspecting load-image mappings. Both explicit and bare-offset forms passed real Ghidra stdio MCP in fresh and selected sessions, both schema profiles; the CLI `--file-offset` path also returned the mapping guidance. This does not settle the selector-design question in #8178 or change project selection. Follow-up: real Ghidra reproduced generic schema-repair advice for an overloaded name and for a file offset mapped to two loaded addresses. The PR now preserves both candidate lists, distinguishes these two producer outcomes, and asks the caller to choose an explicit address. Both candidates succeeded in real full/compact MCP sessions and both outcomes were exercised through the CLI; the targets and selected project were unchanged. This is a controlled fixture on one host, not an autonomous-agent or broad project study.

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 00:29:54 +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#6484

No description provided.

Rows
Columns