morluto/rea

Fork 0

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

[GH-ISSUE #8316] [Design] Isolate invalid Ghidra project configuration from unrelated MCP tools #6543

New issue

Open

opened 2026-11-01 21:12:05 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
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

Should an invalid Ghidra-specific project setting prevent unrelated MCP tools from starting, including a server scoped to a tool family that does not advertise Ghidra tools? If isolation is desired, how should the invalid provider configuration be surfaced without silently ignoring or falling back from a caller-selected project?

Context and evidence

On REA b43c329df779708e43ae297f498a844e45d9c923, Node 24.22.1 and macOS arm64, I started fresh stdio servers with a TypeScript MCP SDK 2.3.1 client:

Launch configuration	Observed result
No Ghidra project setting	Connected; listed 233 tools; `search_guidance` succeeded.
`REA_GHIDRA_PROJECT_PATH` pointing to an owned `.gzf` packed program	Server exited 1 during initialization; SDK reported connection closed. Stderr identified the invalid setting and requested an expanded `.gpr`.
Same invalid setting plus `REA_MCP_TOOL_FAMILIES=application`	Same startup refusal, even though that scope excludes Ghidra analysis tools.
Syntactically valid but nonexistent `.gpr` path	Connected; listed 233 tools; `search_guidance` succeeded. This tests startup only, not target opening.
Valid owned `.gpr` with path-shaped `REA_GHIDRA_PROGRAM_NAME=group/program`	Server exited at startup with the explicit root-program-name error.

The packed program and target were caller-owned. No target was opened or executed in this isolation probe. The separate CLI and doctor correctly reported the invalid configuration; manual .gzf import into a new owned project and subsequent read-only REA analysis were exercised in #3751. Stderr contains the diagnostic, but not every MCP host necessarily shows it; host-specific behavior and autonomous-agent outcomes were not measured.

Expected interaction with targets

No target interaction is required for the unrelated guidance example. Any later Ghidra analysis should keep existing target/project identity and read-only boundaries.

Boundary details (optional)

A configured invalid project must not be treated as absent, silently replaced with a fresh import, or used to bypass admission. Preserve explicit caller provider choices and actionable diagnostics. Distinguish malformed configuration, syntactically valid missing files, selected provider availability and global server configuration; do not weaken security or target validation merely to make startup pass.

Options and tradeoffs

Compare keeping global fail-fast validation with retaining a typed provider-specific configuration error and exposing unrelated tool families. For a catalog that includes Ghidra, consider how binary_session, doctor and an explicit Ghidra request surface the exact problem. An explicitly selected invalid Ghidra configuration should still fail closed. Assess consistency with setup and CLI, client registrations, auto-selection, and cancellation/cleanup before choosing a contract.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise malformed project path and program name, valid-missing projects, unrelated target-free tools, explicit and automatic provider selection, setup/doctor and scoped/full catalogs. Confirm actionable errors and no fresh-import fallback for the selected project. Tests should include real stdio framing and the existing provider boundaries; no real Ghidra launch was needed for the startup probe. No Windows or host-display behavior was tested.

References

Related #3751 (project selection), #1184 (configuration diagnostics), and #7422 (a different empty-override startup bug). The global environment schema and project setting schemas are source-derived context; verify the correct owner before changing validation.

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/8316 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [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 Should an invalid Ghidra-specific project setting prevent unrelated MCP tools from starting, including a server scoped to a tool family that does not advertise Ghidra tools? If isolation is desired, how should the invalid provider configuration be surfaced without silently ignoring or falling back from a caller-selected project? ### Context and evidence On REA `b43c329df779708e43ae297f498a844e45d9c923`, Node 24.22.1 and macOS arm64, I started fresh stdio servers with a TypeScript MCP SDK 2.3.1 client: | Launch configuration | Observed result | | --- | --- | | No Ghidra project setting | Connected; listed 233 tools; `search_guidance` succeeded. | | `REA_GHIDRA_PROJECT_PATH` pointing to an owned `.gzf` packed program | Server exited 1 during initialization; SDK reported connection closed. Stderr identified the invalid setting and requested an expanded `.gpr`. | | Same invalid setting plus `REA_MCP_TOOL_FAMILIES=application` | Same startup refusal, even though that scope excludes Ghidra analysis tools. | | Syntactically valid but nonexistent `.gpr` path | Connected; listed 233 tools; `search_guidance` succeeded. This tests startup only, not target opening. | | Valid owned `.gpr` with path-shaped `REA_GHIDRA_PROGRAM_NAME=group/program` | Server exited at startup with the explicit root-program-name error. | The packed program and target were caller-owned. No target was opened or executed in this isolation probe. The separate CLI and doctor correctly reported the invalid configuration; manual `.gzf` import into a new owned project and subsequent read-only REA analysis were exercised in [#3751](https://github.com/morluto/rea/issues/3751#issuecomment-6544696867). Stderr contains the diagnostic, but not every MCP host necessarily shows it; host-specific behavior and autonomous-agent outcomes were not measured. ### Expected interaction with targets No target interaction is required for the unrelated guidance example. Any later Ghidra analysis should keep existing target/project identity and read-only boundaries. ### Boundary details (optional) A configured invalid project must not be treated as absent, silently replaced with a fresh import, or used to bypass admission. Preserve explicit caller provider choices and actionable diagnostics. Distinguish malformed configuration, syntactically valid missing files, selected provider availability and global server configuration; do not weaken security or target validation merely to make startup pass. ### Options and tradeoffs Compare keeping global fail-fast validation with retaining a typed provider-specific configuration error and exposing unrelated tool families. For a catalog that includes Ghidra, consider how `binary_session`, doctor and an explicit Ghidra request surface the exact problem. An explicitly selected invalid Ghidra configuration should still fail closed. Assess consistency with setup and CLI, client registrations, auto-selection, and cancellation/cleanup before choosing a contract. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise malformed project path and program name, valid-missing projects, unrelated target-free tools, explicit and automatic provider selection, setup/doctor and scoped/full catalogs. Confirm actionable errors and no fresh-import fallback for the selected project. Tests should include real stdio framing and the existing provider boundaries; no real Ghidra launch was needed for the startup probe. No Windows or host-display behavior was tested. ### References Related #3751 (project selection), #1184 (configuration diagnostics), and #7422 (a different empty-override startup bug). The [global environment schema](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/config/environment.ts#L113-L114) and [project setting schemas](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/config/ghidraExistingProject.ts) are source-derived context; verify the correct owner before changing validation. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

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

Author

Owner

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

A positive control with REA_MCP_TOOL_FAMILIES=application and the invalid Ghidra project setting removed connected successfully, listed 21 tools, omitted open_binary, procedure_pseudo_code and annotate_native_function, and returned matching guidance. Adding the .gzf setting produced the startup refusal described above. This isolates the observed difference to the selected launch configuration in this controlled probe; it does not establish whether deferring validation is the right design.

@morluto commented on GitHub (Oct 31, 2026): A positive control with `REA_MCP_TOOL_FAMILIES=application` and the invalid Ghidra project setting removed connected successfully, listed 21 tools, omitted `open_binary`, `procedure_pseudo_code` and `annotate_native_function`, and returned matching guidance. Adding the `.gzf` setting produced the startup refusal described above. This isolates the observed difference to the selected launch configuration in this controlled probe; it does not establish whether deferring validation is the right design.

bsakaguchi commented

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

Author

Owner

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

Missing-project and explicit-provider controls

With a syntactically valid but nonexistent .gpr setting, three fresh real stdio MCP sessions on the same owned arm64 Mach-O behaved as follows:

Explicit provider_id: "ghidra" returned configuration_invalid naming the missing project marker; binary_session remained closed. Guidance worked both before and after the refusal.
Explicit provider_id: "kuna" opened using Kuna 1.986, and procedure_address("_evaluate") returned 0x100000430. The session closed successfully. This is a working unrelated-provider control for a syntactically valid missing Ghidra project, not for the malformed startup configuration.
Omitting provider_id returned capability_unavailable because multiple providers were candidates; the Ghidra missing-project reason appeared among the details. No target remained open. This is a provider-selection ambiguity, not evidence that an automatic fallback was attempted.

The target hash stayed unchanged and it was not executed. Together with the prior malformed-setting startup control, this shows the currently observed distinction between syntax validation at server startup and a valid-shaped missing project encountered during provider selection. It does not prescribe whether either behavior should change or establish behavior when only one auto candidate is installed.

@morluto commented on GitHub (Oct 31, 2026): ### Missing-project and explicit-provider controls With a syntactically valid but nonexistent `.gpr` setting, three fresh real stdio MCP sessions on the same owned arm64 Mach-O behaved as follows: - Explicit `provider_id: "ghidra"` returned `configuration_invalid` naming the missing project marker; `binary_session` remained closed. Guidance worked both before and after the refusal. - Explicit `provider_id: "kuna"` opened using Kuna 1.986, and `procedure_address("_evaluate")` returned `0x100000430`. The session closed successfully. This is a working unrelated-provider control for a syntactically valid missing Ghidra project, not for the malformed startup configuration. - Omitting `provider_id` returned `capability_unavailable` because multiple providers were candidates; the Ghidra missing-project reason appeared among the details. No target remained open. This is a provider-selection ambiguity, not evidence that an automatic fallback was attempted. The target hash stayed unchanged and it was not executed. Together with the prior malformed-setting startup control, this shows the currently observed distinction between syntax validation at server startup and a valid-shaped missing project encountered during provider selection. It does not prescribe whether either behavior should change or establish behavior when only one auto candidate is installed.

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

No description provided.

Rows
Columns