morluto/rea

Fork 0

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

[GH-ISSUE #8821] [Design] Isolate optional provider configuration failures at MCP startup #7763

New issue

Open

opened 2026-11-03 16:33:12 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-03 16:33:12 +00:00

Owner

Originally created by @morluto on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8821

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 a malformed configuration for one optional provider prevent the entire MCP server from initializing, even when the caller needs a different provider or a local inspection tool? If not, how should REA surface the configuration failure without silently ignoring it or weakening fail-closed controls?

Context and evidence

On macOS arm64, REA #8820 head a4b7dfcd1, Node 24.22.1, real Kuna 1.990, Ghidra 12.1.4 and TypeScript MCP SDK 2.3.1, I set REA_GHIDRA_PROJECT_PATH to an owned .gzf packed program, which is invalid for the current expanded-project contract. A fresh stdio MCP connection failed during initialization; the SDK's thrown error was Connection closed. REA's stderr contained the specific setting and the packed-program recovery from #8820. No tools/list or tool call was available in that failed session.

With only that environment variable removed, a fresh server initialized, listed 234 tools, opened the same owned Mach-O with explicit Kuna selection, and completed inspect_macho. The file SHA-256 stayed unchanged and it was not executed. As a separate control, the standalone CLI rea inspect-macho succeeded both with and without the invalid Ghidra setting. The test observed the SDK and captured server stderr directly; it does not establish what any particular MCP host shows its user or what an autonomous agent would do.

Expected interaction with targets

The verified controls read an existing local target and may launch caller-supplied static tools. No target execution or modification is proposed. A possible isolation design would require independent scope and lifecycle review.

Boundary details (optional)

Keep the invalid Ghidra configuration visible as a typed failure, including its recovery, and refuse an explicit request that needs it. Do not silently select a different provider, pretend Ghidra is available, or ignore invalid global transport/security/resource settings. Preserve session, target identity and cleanup semantics. Decide which settings can be isolated without changing their authority or accidentally admitting a partial configuration.

Options and tradeoffs

Compare failing the whole server with better host-visible startup diagnostics, a deliberately limited diagnostic server, and provider-scoped admission that leaves unrelated operations available while reporting Ghidra invalid. Account for MCP host behavior and catalog/availability truthfulness; a diagnostic-only startup must not appear to be a fully healthy server. This is a design question, not a request to implement automatic fallback.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise malformed Ghidra, Kuna, IDA and shared/global settings; explicit and automatic provider selection; unrelated local tools; no viable provider; host-visible diagnostics; fixing the environment and reconnecting; cleanup and cancellation. Distinguish unknown host behavior and preserve invalid-setting details. The current control covers one malformed optional setting and one host; cross-platform behavior and a controlled agent trace are unverified.

References

Related: #8819 / #8820 for the .gzf recovery wording, #8565 for unsupported-provider discovery after a session starts, and #3751 for existing-project selection. CLI rea doctor already reports this setting as config_drift; this question concerns the MCP server being unable to start and serve any tool.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Source-derived boundary

At #8820 head a4b7dfcd1, src/main.ts snapshots the environment and calls parseConfig before selecting deferred or eager MCP startup. parseConfig admits the combined native-analysis environment, including the Ghidra project setting; any resulting configuration error is written to stderr and returns before server creation. This is consistent with the observed initialization failure. The standalone CLI control demonstrates that at least the tested inspect-macho path does not require that same admission. This is source-derived reasoning for the control, not proof that every optional setting can safely be deferred.

Scoped-registration control

On the same checkout and host, I started a fresh stdio MCP server with REA_MCP_TOOL_FAMILIES=pcap. With the Ghidra project setting absent, it initialized and listed two packet-capture tools, including inspect_pcap_capture, without advertising procedure_pseudo_code. Adding the same invalid .gzf project setting made SDK initialization fail with Connection closed; the setting-specific diagnostic was on server stderr. No packet capture was opened in this control. This shows that catalog scoping alone does not currently isolate this provider-specific configuration error; it does not establish which other family or configuration failures can safely be isolated.

Existing isolation precedent and configuration matrix

On the same #8820 checkout and host, separate fresh REA_MCP_TOOL_FAMILIES=pcap stdio sessions produced these results:

Single setting	Startup	Observation
none	initialized	two packet-capture tools listed
invalid `.gzf` Ghidra project path	failed	SDK `Connection closed`; setting diagnostic on stderr
relative `REA_IDA_MCP_CONFIG`	failed	SDK `Connection closed`; setting diagnostic on stderr
malformed `REA_JEB_MCP_URL`	initialized	packet-capture tools listed
relative `REA_KUNA_COMMAND`	initialized	packet-capture tools listed
`REA_MCP_MAX_RESPONSE_BYTES=1`	failed	SDK `Connection closed`; transport-budget diagnostic on stderr

A separate unscoped session with the same invalid Kuna command initialized, but an explicit Kuna open_binary returned provider_unavailable, identified open_options_invalid, and named REA_KUNA_COMMAND in its recovery. This is an observed example of leaving an unrelated catalog available while refusing the malformed provider selection. Source inspection also shows nativeAnalysisEnvironment intentionally excludes JEB-only URL and timeout settings from aggregate native admission; Kuna parses its own configuration. This does not establish that Ghidra and IDA settings have identical owners or that all can be moved safely. Invalid shared transport limits are a separate fail-closed case and must not be silently replaced with defaults.

Ownership constraint from source

Ghidra project configuration has cross-setting rules: a program name requires a project, and an existing project conflicts with import/analysis overrides. parseConfig turns the validated project and name into a single ghidraExistingProject selection; the IDA provider similarly consumes a validated registration path. Simply deleting bad fields or replacing them with defaults would lose the caller's choice and could cause Ghidra to import a fresh program instead of refusing the selected project. Any isolation work needs to carry the provider-owned invalid result through composition and readiness, while preserving all coupled settings and distinguishing unavailable from unconfigured. This is a source-derived design constraint, not an implemented prototype or assertion that a particular refactor is safe.

Syntactically valid but missing project

On the same #8820 checkout and host, a fresh server configured with an absolute, nonexistent missing.gpr and a program name initialized. An explicit Ghidra open_binary failed with configuration_invalid, REA_GHIDRA_PROJECT_PATH and an ENOENT diagnostic. Selecting Kuna explicitly afterward succeeded and produced pseudocode for the same unchanged target. In a separate status call while Kuna was active, the Ghidra candidate reported host availability: available and target support supported: its installation was valid, even though the configured project could not be opened. rea doctor --provider ghidra --target <target> similarly reported healthy host/target checks. REA's documentation describes these provider checks as host-level, so this is not presented as a false installation claim or a guarantee that a project is usable.

For an isolation design, this means host installation readiness, syntactic configuration validity, project accessibility, target applicability and actual program/target identity are distinct facts. Moving a malformed project setting out of global startup must not turn it into a fresh-import choice or imply that checking the executable alone established project readiness. A missing .gpr control does not prove behavior for malformed project contents, changed identities or concurrent edits.

Failed selection preserves an existing session

With the same missing .gpr configuration, separate real compact and full MCP sessions first opened the target explicitly with Kuna and resolved a function. Each complete status reported Ghidra's host available and the target format supported. Explicitly selecting Ghidra then failed with the project configuration error; the following Kuna lookup still succeeded with the same Evidence ID and Kuna attribution. Successful replies validated against their advertised schemas, and the target digest was unchanged. This verifies the existing failure-preservation behavior for this one missing-project path; an isolation change should retain it rather than terminating or replacing a usable binding.

Automatic selection after an isolated Kuna configuration error

On the Kuna 1.990 validation checkout, with REA_KUNA_COMMAND=relative/kuna, an owned arm64 Mach-O and real Ghidra 12.1.4 / JDK 21 on macOS arm64, fresh compact and full MCP sessions both initialized. open_binary without an explicit provider returned capability_unavailable with selection_reason: ambiguous: Ghidra and Hopper were candidates, while Kuna appeared in rejections as open_options_invalid with the invalid setting and its correction. On each same connection, explicit Ghidra selection then succeeded and procedure_pseudo_code returned Ghidra-attributed Evidence. The target SHA-256 stayed unchanged. This tests the existing isolated Kuna configuration path and a multiple-provider host; it does not establish how automatic selection behaves when there is only one viable provider or no viable provider, or imply that malformed Ghidra settings are already isolated.

One and zero viable providers with an invalid Kuna setting

On the same validation checkout and host, REA_KUNA_COMMAND=relative/kuna and a nonexistent absolute Hopper launcher left Ghidra as the sole viable provider. In compact and full MCP sessions, automatic open_binary succeeded and pseudocode returned Ghidra-attributed Evidence. When a nonexistent absolute Ghidra installation was also selected, both profiles still opened the Mach-O as a session target; the subsequent pseudocode request returned provider_unavailable, with separate Ghidra, Hopper, IDA and Kuna readiness diagnostics including the invalid Kuna setting. binary_session then showed the target open and no analysis-provider binding, and inspect_macho succeeded on the same connection. The target hash remained unchanged. This control distinguishes target admission from deep-provider readiness; it exercises one host and this combination of unavailable settings, not every provider failure or host client UX.

Multiple invalid provider settings

On PR #8829 head 33f2d251e (based on main c3647ade1, with byte-tool description changes only), with Node 24.22.1 on macOS arm64, starting stdio MCP with both a .gzf Ghidra project path and a relative IDA MCP configuration path exited 1 before initialization. Captured stderr named both REA_IDA_MCP_CONFIG and REA_GHIDRA_PROJECT_PATH and their respective constraints. This checks aggregate startup diagnostics on this combination; it does not show what any MCP host displays to an agent.

Provider-scoped admission must retain multiple independent invalid selections rather than dropping all but the first, while continuing to reject invalid shared settings and preserving each explicit configuration. The test did not open or execute a target.

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8821 ### 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 a malformed configuration for one optional provider prevent the entire MCP server from initializing, even when the caller needs a different provider or a local inspection tool? If not, how should REA surface the configuration failure without silently ignoring it or weakening fail-closed controls? ### Context and evidence On macOS arm64, REA #8820 head `a4b7dfcd1`, Node 24.22.1, real Kuna 1.990, Ghidra 12.1.4 and TypeScript MCP SDK 2.3.1, I set `REA_GHIDRA_PROJECT_PATH` to an owned `.gzf` packed program, which is invalid for the current expanded-project contract. A fresh stdio MCP connection failed during initialization; the SDK's thrown error was `Connection closed`. REA's stderr contained the specific setting and the packed-program recovery from #8820. No `tools/list` or tool call was available in that failed session. With only that environment variable removed, a fresh server initialized, listed 234 tools, opened the same owned Mach-O with explicit Kuna selection, and completed `inspect_macho`. The file SHA-256 stayed unchanged and it was not executed. As a separate control, the standalone CLI `rea inspect-macho` succeeded both with and without the invalid Ghidra setting. The test observed the SDK and captured server stderr directly; it does not establish what any particular MCP host shows its user or what an autonomous agent would do. ### Expected interaction with targets The verified controls read an existing local target and may launch caller-supplied static tools. No target execution or modification is proposed. A possible isolation design would require independent scope and lifecycle review. ### Boundary details (optional) Keep the invalid Ghidra configuration visible as a typed failure, including its recovery, and refuse an explicit request that needs it. Do not silently select a different provider, pretend Ghidra is available, or ignore invalid global transport/security/resource settings. Preserve session, target identity and cleanup semantics. Decide which settings can be isolated without changing their authority or accidentally admitting a partial configuration. ### Options and tradeoffs Compare failing the whole server with better host-visible startup diagnostics, a deliberately limited diagnostic server, and provider-scoped admission that leaves unrelated operations available while reporting Ghidra invalid. Account for MCP host behavior and catalog/availability truthfulness; a diagnostic-only startup must not appear to be a fully healthy server. This is a design question, not a request to implement automatic fallback. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise malformed Ghidra, Kuna, IDA and shared/global settings; explicit and automatic provider selection; unrelated local tools; no viable provider; host-visible diagnostics; fixing the environment and reconnecting; cleanup and cancellation. Distinguish unknown host behavior and preserve invalid-setting details. The current control covers one malformed optional setting and one host; cross-platform behavior and a controlled agent trace are unverified. ### References Related: #8819 / #8820 for the `.gzf` recovery wording, #8565 for unsupported-provider discovery after a session starts, and #3751 for existing-project selection. CLI `rea doctor` already reports this setting as `config_drift`; this question concerns the MCP server being unable to start and serve any tool. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Source-derived boundary At #8820 head `a4b7dfcd1`, `src/main.ts` snapshots the environment and calls `parseConfig` before selecting deferred or eager MCP startup. `parseConfig` admits the combined native-analysis environment, including the Ghidra project setting; any resulting configuration error is written to stderr and returns before server creation. This is consistent with the observed initialization failure. The standalone CLI control demonstrates that at least the tested `inspect-macho` path does not require that same admission. This is source-derived reasoning for the control, not proof that every optional setting can safely be deferred. ### Scoped-registration control On the same checkout and host, I started a fresh stdio MCP server with `REA_MCP_TOOL_FAMILIES=pcap`. With the Ghidra project setting absent, it initialized and listed two packet-capture tools, including `inspect_pcap_capture`, without advertising `procedure_pseudo_code`. Adding the same invalid `.gzf` project setting made SDK initialization fail with `Connection closed`; the setting-specific diagnostic was on server stderr. No packet capture was opened in this control. This shows that catalog scoping alone does not currently isolate this provider-specific configuration error; it does not establish which other family or configuration failures can safely be isolated. ### Existing isolation precedent and configuration matrix On the same #8820 checkout and host, separate fresh `REA_MCP_TOOL_FAMILIES=pcap` stdio sessions produced these results: | Single setting | Startup | Observation | | --- | --- | --- | | none | initialized | two packet-capture tools listed | | invalid `.gzf` Ghidra project path | failed | SDK `Connection closed`; setting diagnostic on stderr | | relative `REA_IDA_MCP_CONFIG` | failed | SDK `Connection closed`; setting diagnostic on stderr | | malformed `REA_JEB_MCP_URL` | initialized | packet-capture tools listed | | relative `REA_KUNA_COMMAND` | initialized | packet-capture tools listed | | `REA_MCP_MAX_RESPONSE_BYTES=1` | failed | SDK `Connection closed`; transport-budget diagnostic on stderr | A separate unscoped session with the same invalid Kuna command initialized, but an explicit Kuna `open_binary` returned `provider_unavailable`, identified `open_options_invalid`, and named `REA_KUNA_COMMAND` in its recovery. This is an observed example of leaving an unrelated catalog available while refusing the malformed provider selection. Source inspection also shows `nativeAnalysisEnvironment` intentionally excludes JEB-only URL and timeout settings from aggregate native admission; Kuna parses its own configuration. This does not establish that Ghidra and IDA settings have identical owners or that all can be moved safely. Invalid shared transport limits are a separate fail-closed case and must not be silently replaced with defaults. ### Ownership constraint from source Ghidra project configuration has cross-setting rules: a program name requires a project, and an existing project conflicts with import/analysis overrides. `parseConfig` turns the validated project and name into a single `ghidraExistingProject` selection; the IDA provider similarly consumes a validated registration path. Simply deleting bad fields or replacing them with defaults would lose the caller's choice and could cause Ghidra to import a fresh program instead of refusing the selected project. Any isolation work needs to carry the provider-owned invalid result through composition and readiness, while preserving all coupled settings and distinguishing unavailable from unconfigured. This is a source-derived design constraint, not an implemented prototype or assertion that a particular refactor is safe. ### Syntactically valid but missing project On the same #8820 checkout and host, a fresh server configured with an absolute, nonexistent `missing.gpr` and a program name initialized. An explicit Ghidra `open_binary` failed with `configuration_invalid`, `REA_GHIDRA_PROJECT_PATH` and an `ENOENT` diagnostic. Selecting Kuna explicitly afterward succeeded and produced pseudocode for the same unchanged target. In a separate status call while Kuna was active, the Ghidra candidate reported host `availability: available` and target support `supported`: its installation was valid, even though the configured project could not be opened. `rea doctor --provider ghidra --target <target>` similarly reported healthy host/target checks. REA's documentation describes these provider checks as host-level, so this is not presented as a false installation claim or a guarantee that a project is usable. For an isolation design, this means host installation readiness, syntactic configuration validity, project accessibility, target applicability and actual program/target identity are distinct facts. Moving a malformed project setting out of global startup must not turn it into a fresh-import choice or imply that checking the executable alone established project readiness. A missing `.gpr` control does not prove behavior for malformed project contents, changed identities or concurrent edits. ### Failed selection preserves an existing session With the same missing `.gpr` configuration, separate real compact and full MCP sessions first opened the target explicitly with Kuna and resolved a function. Each complete status reported Ghidra's host available and the target format supported. Explicitly selecting Ghidra then failed with the project configuration error; the following Kuna lookup still succeeded with the same Evidence ID and Kuna attribution. Successful replies validated against their advertised schemas, and the target digest was unchanged. This verifies the existing failure-preservation behavior for this one missing-project path; an isolation change should retain it rather than terminating or replacing a usable binding. ### Automatic selection after an isolated Kuna configuration error On the Kuna 1.990 validation checkout, with `REA_KUNA_COMMAND=relative/kuna`, an owned arm64 Mach-O and real Ghidra 12.1.4 / JDK 21 on macOS arm64, fresh compact and full MCP sessions both initialized. `open_binary` without an explicit provider returned `capability_unavailable` with `selection_reason: ambiguous`: Ghidra and Hopper were candidates, while Kuna appeared in rejections as `open_options_invalid` with the invalid setting and its correction. On each same connection, explicit Ghidra selection then succeeded and `procedure_pseudo_code` returned Ghidra-attributed Evidence. The target SHA-256 stayed unchanged. This tests the existing isolated Kuna configuration path and a multiple-provider host; it does not establish how automatic selection behaves when there is only one viable provider or no viable provider, or imply that malformed Ghidra settings are already isolated. ### One and zero viable providers with an invalid Kuna setting On the same validation checkout and host, `REA_KUNA_COMMAND=relative/kuna` and a nonexistent absolute Hopper launcher left Ghidra as the sole viable provider. In compact and full MCP sessions, automatic `open_binary` succeeded and pseudocode returned Ghidra-attributed Evidence. When a nonexistent absolute Ghidra installation was also selected, both profiles still opened the Mach-O as a session target; the subsequent pseudocode request returned `provider_unavailable`, with separate Ghidra, Hopper, IDA and Kuna readiness diagnostics including the invalid Kuna setting. `binary_session` then showed the target open and no analysis-provider binding, and `inspect_macho` succeeded on the same connection. The target hash remained unchanged. This control distinguishes target admission from deep-provider readiness; it exercises one host and this combination of unavailable settings, not every provider failure or host client UX. ### Multiple invalid provider settings On PR #8829 head `33f2d251e` (based on main `c3647ade1`, with byte-tool description changes only), with Node 24.22.1 on macOS arm64, starting stdio MCP with both a `.gzf` Ghidra project path and a relative IDA MCP configuration path exited 1 before initialization. Captured stderr named **both** `REA_IDA_MCP_CONFIG` and `REA_GHIDRA_PROJECT_PATH` and their respective constraints. This checks aggregate startup diagnostics on this combination; it does not show what any MCP host displays to an agent. Provider-scoped admission must retain multiple independent invalid selections rather than dropping all but the first, while continuing to reject invalid shared settings and preserving each explicit configuration. The test did not open or execute a target.

bsakaguchi referenced this issue

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

[GH-ISSUE #7763] [Bug] capture_browser_scenario: a response with HTTP status above 599 throws a ZodError in a Playwright event handler and ends the MCP server #4637

bsakaguchi commented

2026-11-04 13:11:24 +00:00

Author

Owner

@macjayz commented on GitHub (Nov 4, 2026):

What one MCP host shows the agent

The evidence above leaves host behavior open, so I checked one host. Setup: current main 2d16a40a4 (with the duplicate childNodes import from #8884/#8886 removed locally so it compiles), Node 26.12.1 on macOS arm64, REA_MCP_TOOL_FAMILIES=pcap, and REA_GHIDRA_PROJECT_PATH set to an owned .gzf-named file. Run directly, the server exits 1 before initialization. Its stderr is REA configuration is invalid: REA_GHIDRA_PROJECT_PATH: Select an expanded .gpr project marker; restore .grez archives first.

I then ran Claude Code 2.1.119 as the host (claude -p with --strict-mcp-config and only this server):

Setting	Host init status	rea tools offered to the model	Model's answer to "is rea connected, and why not?"
none	`{"name":"rea","status":"connected"}`	`inspect_pcap_capture`, `inspect_pcap_client`	n/a
`.gzf` project path	`{"name":"rea","status":"failed"}`	none	it could not see rea and could not name a reason

The setting-specific text did not reach the model. Claude Code only wrote it to its per-project MCP log (~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-rea/*.jsonl), as Server stderr: REA configuration is invalid: …, next to Connection failed: MCP error -32000: Connection closed. For this host, better startup diagnostics on stderr alone would reach a person reading logs, not the agent. Only something REA serves over the protocol would reach the agent. This is one host, one version and a non-interactive run. I did not check what the interactive /mcp view shows.

A possible shape for provider-scoped admission

The Kuna path already fits the constraints above, so Ghidra could follow the same pattern:

Keep the Ghidra existing-project group together. Admit REA_GHIDRA_PROJECT_PATH, REA_GHIDRA_PROGRAM_NAME and the import/analysis overrides that conflict with them as one unit. The result is either a valid ghidraExistingProject selection or a retained ConfigurationError that lists every invalid setting. It is never "unset", so a bad project cannot turn into a fresh import.
Carry the invalid result as Ghidra availability, as KunaConfigurationFailure does with open_options_invalid, setting and remediation. An explicit Ghidra open_binary then fails with the existing configuration_invalid projection and its details.settings. Automatic selection lists Ghidra in its rejections. Status and doctor report Ghidra as configuration-invalid, not as available with only host checks.
Keep shared settings fatal. REA_MCP_* transport, schema and resource limits still stop startup, because no part of the server can safely run with them invalid. Multiple invalid provider groups (Ghidra and IDA together) each keep their own retained error.

This would remove the .gzf and relative-IDA rows of the matrix from startup failure, and would not hide the error. The limited diagnostic server would still be the only option that helps an agent with invalid shared settings. I'd suggest deciding that separately, since it carries the "looks healthy" risk the issue names.

Not verified: other hosts (Claude Desktop, Codex, Cursor), Windows, the interactive host UI, and any implementation of the shape above.

@macjayz commented on GitHub (Nov 4, 2026): ### What one MCP host shows the agent The evidence above leaves host behavior open, so I checked one host. Setup: current main `2d16a40a4` (with the duplicate `childNodes` import from #8884/#8886 removed locally so it compiles), Node 26.12.1 on macOS arm64, `REA_MCP_TOOL_FAMILIES=pcap`, and `REA_GHIDRA_PROJECT_PATH` set to an owned `.gzf`-named file. Run directly, the server exits 1 before initialization. Its stderr is `REA configuration is invalid: REA_GHIDRA_PROJECT_PATH: Select an expanded .gpr project marker; restore .grez archives first.` I then ran Claude Code 2.1.119 as the host (`claude -p` with `--strict-mcp-config` and only this server): | Setting | Host init status | rea tools offered to the model | Model's answer to "is rea connected, and why not?" | | --- | --- | --- | --- | | none | `{"name":"rea","status":"connected"}` | `inspect_pcap_capture`, `inspect_pcap_client` | n/a | | `.gzf` project path | `{"name":"rea","status":"failed"}` | none | it could not see rea and could not name a reason | The setting-specific text did not reach the model. Claude Code only wrote it to its per-project MCP log (`~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-rea/*.jsonl`), as `Server stderr: REA configuration is invalid: …`, next to `Connection failed: MCP error -32000: Connection closed`. For this host, better startup diagnostics on stderr alone would reach a person reading logs, not the agent. Only something REA serves over the protocol would reach the agent. This is one host, one version and a non-interactive run. I did not check what the interactive `/mcp` view shows. ### A possible shape for provider-scoped admission The Kuna path already fits the constraints above, so Ghidra could follow the same pattern: 1. **Keep the Ghidra existing-project group together.** Admit `REA_GHIDRA_PROJECT_PATH`, `REA_GHIDRA_PROGRAM_NAME` and the import/analysis overrides that conflict with them as one unit. The result is either a valid `ghidraExistingProject` selection or a retained `ConfigurationError` that lists every invalid setting. It is never "unset", so a bad project cannot turn into a fresh import. 2. **Carry the invalid result as Ghidra availability**, as `KunaConfigurationFailure` does with `open_options_invalid`, `setting` and `remediation`. An explicit Ghidra `open_binary` then fails with the existing `configuration_invalid` projection and its `details.settings`. Automatic selection lists Ghidra in its rejections. Status and doctor report Ghidra as configuration-invalid, not as `available` with only host checks. 3. **Keep shared settings fatal.** `REA_MCP_*` transport, schema and resource limits still stop startup, because no part of the server can safely run with them invalid. Multiple invalid provider groups (Ghidra and IDA together) each keep their own retained error. This would remove the `.gzf` and relative-IDA rows of the matrix from startup failure, and would not hide the error. The limited diagnostic server would still be the only option that helps an agent with invalid shared settings. I'd suggest deciding that separately, since it carries the "looks healthy" risk the issue names. Not verified: other hosts (Claude Desktop, Codex, Cursor), Windows, the interactive host UI, and any implementation of the shape above.

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

No description provided.

Rows
Columns