[GH-ISSUE #5771] [Bug] Preserve IDA registration settings in provider recovery diagnostics #3505

Closed
opened 2026-10-31 00:41:16 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @gensokyo-dev on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5771

Before submitting

  • Searched related open/closed IDA registration and recovery reports; not a FIFO/descriptor or partial-decompilation issue.
  • Removed credentials and private path prefixes.

Area

Provider/capability discovery; MCP recovery.

Observed behavior

An explicit open_binary request for provider_id: "ida", with REA_IDA_MCP_CONFIG selecting a missing JSON file, returns provider_unavailable / open_options_invalid. The selected rejection says the registration cannot be read, but loses the structured configuration setting and reports configured: false despite a caller-selected path.

In an actual Codex CLI 0.161.0 / gpt-6.1-sol trial, the agent made the opening call, queried binary_session twice, closed the session, and explicitly reported: the exposed contracts did not identify the configuration key. No IDA connection or analysis was performed.

Reproduction

At df8b4d8a5a8c218ac9f49dd75e014bd910209d36 (IDA code unchanged in the WABT follow-up): start production stdio MCP with an absolute nonexistent REA_IDA_MCP_CONFIG path. Call:

{"name":"open_binary","arguments":{"path":"/usr/bin/true","provider_id":"ida"}}

Observe the selected IDA rejection's reason and diagnostics. Public MCP and the real agent trial reproduced it; no real IDA engine was used.

Expected behavior

Preserve the typed configuration owner's already-parsed setting/recovery details through provider readiness and selection. Name REA_IDA_MCP_CONFIG and the caller-selected registration path. Distinguish selected configuration from successful validation/readiness; missing or malformed input must stay unavailable and must not initiate an IDA connection.

Impact and scope

The agent cannot give the exact actionable configuration change without guessing or consulting outside documentation; repeated status queries do not recover the lost fact. A safe stop is not a complete agent-friendly recovery pass. Broader model rates are unknown. Existing IdaConfiguration.idaConfigurationError already owns the setting in ConfigurationError.settings; IdaProvider.inspectReadinessSnapshot currently projects only the plain error message and hardcodes configured: false on every failure.

Runtime / artifact / interface / stage

REA 6.7.0, Node 24.18.0, Debian 12 Linux x64; /usr/bin/true selected but not opened/analyzed. MCP; earliest stage: provider admission/readiness. No target execution, attached GUI control, installation or configuration mutation.

Evidence and proposed checks

Exact raw calls/final answer retained in the local provider-recovery acceptance receipts. Proposed guards: unconfigured, missing, malformed and valid registration states, no connection during readiness, CLI/MCP error guidance, and repeated real Codex negative tasks. Keep cancellation, descriptor ownership and cleanup unchanged.

Originally created by @gensokyo-dev on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5771 ## Before submitting - [x] Searched related open/closed IDA registration and recovery reports; not a FIFO/descriptor or partial-decompilation issue. - [x] Removed credentials and private path prefixes. ## Area Provider/capability discovery; MCP recovery. ## Observed behavior An explicit `open_binary` request for `provider_id: "ida"`, with `REA_IDA_MCP_CONFIG` selecting a missing JSON file, returns `provider_unavailable` / `open_options_invalid`. The selected rejection says the registration cannot be read, but loses the structured configuration setting and reports `configured: false` despite a caller-selected path. In an actual Codex CLI 0.161.0 / `gpt-6.1-sol` trial, the agent made the opening call, queried `binary_session` twice, closed the session, and explicitly reported: **the exposed contracts did not identify the configuration key**. No IDA connection or analysis was performed. ## Reproduction At `df8b4d8a5a8c218ac9f49dd75e014bd910209d36` (IDA code unchanged in the WABT follow-up): start production stdio MCP with an absolute nonexistent `REA_IDA_MCP_CONFIG` path. Call: ```json {"name":"open_binary","arguments":{"path":"/usr/bin/true","provider_id":"ida"}} ``` Observe the selected IDA rejection's reason and diagnostics. Public MCP and the real agent trial reproduced it; no real IDA engine was used. ## Expected behavior Preserve the typed configuration owner's already-parsed setting/recovery details through provider readiness and selection. Name `REA_IDA_MCP_CONFIG` and the caller-selected registration path. Distinguish selected configuration from successful validation/readiness; missing or malformed input must stay unavailable and must not initiate an IDA connection. ## Impact and scope The agent cannot give the exact actionable configuration change without guessing or consulting outside documentation; repeated status queries do not recover the lost fact. A safe stop is not a complete agent-friendly recovery pass. Broader model rates are unknown. Existing `IdaConfiguration.idaConfigurationError` already owns the setting in `ConfigurationError.settings`; `IdaProvider.inspectReadinessSnapshot` currently projects only the plain error message and hardcodes `configured: false` on every failure. ## Runtime / artifact / interface / stage REA 6.7.0, Node 24.18.0, Debian 12 Linux x64; `/usr/bin/true` selected but not opened/analyzed. MCP; earliest stage: provider admission/readiness. No target execution, attached GUI control, installation or configuration mutation. ## Evidence and proposed checks Exact raw calls/final answer retained in the local provider-recovery acceptance receipts. Proposed guards: unconfigured, missing, malformed and valid registration states, no connection during readiness, CLI/MCP error guidance, and repeated real Codex negative tasks. Keep cancellation, descriptor ownership and cleanup unchanged.
bsakaguchi 2026-10-31 00:41:16 +00:00
  • closed this issue
  • added the
    bug
    triage
    labels
Author
Owner

@gensokyo-dev commented on GitHub (Oct 21, 2026):

Fixed and merged in #5773. Five new readiness regressions failed on the base; 84 relevant tests and static/docs checks passed after the fix. Production CLI/MCP selected-IDA errors preserve the same setting/path/recovery facts. Two actual Codex CLI follow-ups named REA_IDA_MCP_CONFIG and the MCP launch-environment/restart boundary in two calls each; the historical baseline used four calls and explicitly could not identify the key. No real IDA engine/GUI analysis is claimed. Full cross-provider results are recorded under #5598.

<!-- gh-comment-id:6308251091 --> @gensokyo-dev commented on GitHub (Oct 21, 2026): Fixed and merged in #5773. Five new readiness regressions failed on the base; 84 relevant tests and static/docs checks passed after the fix. Production CLI/MCP selected-IDA errors preserve the same setting/path/recovery facts. Two actual Codex CLI follow-ups named REA_IDA_MCP_CONFIG and the MCP launch-environment/restart boundary in two calls each; the historical baseline used four calls and explicitly could not identify the key. No real IDA engine/GUI analysis is claimed. Full cross-provider results are recorded under #5598.
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#3505
No description provided.