morluto/rea

Fork 0

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

[PR #1732] fix(setup): preserve user fields on an existing REA client entry #4782

New issue

Open

opened 2026-10-31 00:55:00 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:55:00 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1732
Author: @xeropresence
Created: 10/11/2026
Status: 🔄 Open

Base: main ← Head: fix/setup-preserve-entry-fields

📝 Commits (10+)

c136ba3 fix(setup): preserve user fields on an existing REA client entry
768a2c4 fix(setup): drop stale Codex oauth_resource and disclose remote replacement
b576d83 fix(setup): disclose remote-key removal in the approval plan
887907c fix(setup): drop stale Qwen tcp endpoints and name rewritten entry keys
d9d87df fix(setup): drop non-boolean activation switches from retained entries
e5910e6 fix(setup): retain only registration fields doctor can parse
2e9320f refactor(setup): accept retained fields from the registration schema
a088312 fix(setup): describe the inspected OpenCode registration dialect
6e4a431 fix(setup): match retained fields to the client that writes them
6297d5f fix(setup): drop ZCode's enable: false from retained entries

📊 Changes

19 files changed (+892 additions, -64 deletions)

View changed files

📝 docs/installation.md (+15 -0)
📝 src/application/ClientConfigurationDocument.ts (+145 -0)
➕ src/application/ClientRegistrationShape.test.ts (+27 -0)
➕ src/application/ClientRegistrationShape.ts (+81 -0)
📝 src/application/ClientRegistrationStatus.ts (+12 -22)
📝 src/application/DshCordisPatch.ts (+12 -0)
📝 src/application/Setup.planning.test.ts (+121 -0)
📝 src/application/SetupClientConfiguration.ts (+39 -30)
📝 src/application/SetupPlan.ts (+23 -5)
📝 src/application/SetupTypes.ts (+8 -1)
📝 tests/boundary/filesystem/claudeDesktopClientConfiguration.test.ts (+3 -2)
📝 tests/boundary/filesystem/clientConfigurationBom.test.ts (+4 -0)
📝 tests/boundary/filesystem/clientConfigurationEnvironment.test.ts (+1 -1)
📝 tests/boundary/filesystem/clientConfigurationLayeredEnvironment.test.ts (+3 -2)
📝 tests/boundary/filesystem/clientConfigurationTransactions.test.ts (+1 -0)
➕ tests/boundary/filesystem/clientRegistrationFields.test.ts (+343 -0)
📝 tests/boundary/filesystem/dshClientConfiguration.test.ts (+8 -0)
📝 tests/boundary/filesystem/ompClientConfiguration.test.ts (+45 -0)
📝 tests/boundary/filesystem/piClientConfiguration.test.ts (+1 -1)

📄 Description

Summary

Re-running rea setup on a client that already has a rea server entry
rewrote that entry from scratch. Environment overrides were carried over (since
#1607), but every other field the user had added was lost. The visible case: an
OMP entry with "timeout": 0 (OMP's MCP request timeout; 0 turns it off, which
long IDA analyses need) came back without timeout, so the next long request
timed out.

Setup now changes only the keys REA owns in its entry and keeps the rest. A
second setup run makes no change, and rea doctor still reports the entry as
aligned.

No issue is linked; this was found while running REA under Bun with an IDA
provider registration in OMP.

Problem and expected behavior

Smallest trigger (~/.omp/agent/mcp.json):

{ "mcpServers": { "rea": {
  "type": "stdio", "command": "C:\\old\\bun.exe", "args": ["C:\\old\\rea.mjs", "mcp"],
  "env": { "REA_ANALYSIS_PROVIDER": "ida", "REA_IDA_MCP_CONFIG": "C:\\ida-mcp.json" },
  "timeout": 0
} } }

rea setup --client omp --yes wrote {type, command, args, env}, without
timeout. That breaks AGENTS.md's rule that configuration changes are additive.
The setup plan already said "Existing server environment overrides are
retained", so users had no reason to expect other fields to go.

Expected: the new command/args replace the stale launcher, env is kept and
merged as before, and timeout stays.

Change and scope

The desired entry is built in one place,
clientConfigurationDesired (src/application/SetupClientConfiguration.ts).
Setup writes it, and both alignment checks (setup preflight, --dry-run, and
clientConfigurationAligned) compare against it. That function now passes REA's
fresh entry through a new retainClientRegistrationFields(dialect, existing, registration) in ClientConfigurationDocument.ts. Because the merge happens
there, every writer (JSON/JSONC, Codex TOML, Grok TOML, Hermes YAML, OpenCode
V1/V2) and every "is it current?" check sees the same merged entry, so setup stays
idempotent.

Rules:

REA-owned keys get REA's values: the launch keys command, args, type,
transport, env/environment, plus anything REA's entry sets for that
dialect (tools for Copilot CLI, enabled: true for OpenCode V1/Command
Code/Hermes, startup_timeout_sec for Codex and Grok Build). If REA's new entry
leaves out a launch key, the existing one is removed. For example, a stale
type: "http" is removed from a JSON entry, and an empty env map is not left
behind.
Keys that contradict a local stdio entry are removed: url, httpUrl,
serverUrl, headers, http_headers, env_http_headers,
bearer_token_env_var, oauth. Keeping a stale url beside the new command
could make a client pick the remote transport or reject the entry.
Entry-level off switches are removed: enabled: false, and disabled: true except on Grok Build. Setup's job is an active registration, and it
already removes rea from OMP's disabledServers and Grok's
disabled_mcp_servers for the same reason. Grok's entry-level disabled is
kept because registration status does not treat it as an off switch for Grok
either.
Everything else is kept: e.g. OMP/Pi timeout, enabled: true,
instructions; Codex tool_timeout_sec, enabled_tools; Gemini/Cursor
timeout, trust; Hermes timeout, connect_timeout. Existing key order is
kept, and new REA keys are added at the end.
Remote entries are replaced whole: if the existing rea entry has no
command, it is a remote server, and setup replaces it entirely as before.
Merging its remote-only fields into a local entry would be wrong.
Legacy OpenCode V1 → V2 migration: only the entry in the table being
written is used as the base. A V1 mcp.rea entry that moves into a native
mcp.servers table keeps only its environment (as before), because its other
fields use the V1 shape.

Every writable dialect is covered. Clients with format unsupported (manual
registration) have no entry for setup to merge, so nothing changes for them.

Not included: preserving comments inside the rea entry itself (the JSONC writer
still replaces the entry value as one unit; comments elsewhere in the file were
already kept), and any change to uninstall.

Contract and boundary impact

Semantic owner and earliest changed stage: clientConfigurationDesired in
src/application/SetupClientConfiguration.ts, using the new
retainClientRegistrationFields in src/application/ClientConfigurationDocument.ts.
CLI and MCP/tool-catalog contract: no new commands or flags. The setup plan's
client detail now also says that other fields on REA's existing entry are
retained (the existing "Existing server environment overrides are retained"
wording is unchanged).
Provider, bridge, target-format, or platform compatibility: applies to every
writable client dialect; no provider change.
Evidence, artifact, provenance, or reconstruction contract: not applicable.
Process execution, authorization, cleanup, or containment impact: none. Writes
still go through the same backup, atomic-replace, and read-back path.
Generated metadata, package, or installation impact: none. docs/installation.md
describes which keys setup rewrites, removes, and keeps.

Evidence and regression coverage

Tests added or updated:
- tests/boundary/filesystem/clientRegistrationFields.test.ts (new): one case
  for each writable dialect (Cursor JSON, VS Code, OMP, Pi, Copilot CLI, Command
  Code, OpenCode V1, OpenCode V2, Codex TOML, Grok Build TOML, Hermes YAML). It
  seeds an entry with a stale command, env, dialect-specific user fields, a
  stale url and enabled: false, then runs inspectClientConfiguration →
  update, configureClientConfiguration → configured. It checks that the
  entry equals REA's entry plus the user fields, that
  clientConfigurationAligned → true and inspect → already_current, and
  that a second configure → unchanged with byte-identical file text. One more
  case checks that a remote entry (no command) is still replaced whole.
- tests/boundary/filesystem/ompClientConfiguration.test.ts: the reported OMP
  case with timeout: 0 and an env override. It checks setup output,
  second-run byte identity, and readClientRegistrationStatuses → aligned.
Base reproduction: with src/ checked out from the base commit (0ecf3f24),
all 12 field-retention tests fail (11 dialect cases plus the OMP timeout case),
because the extra fields are dropped. The remote-entry test passes on base,
since that behavior did not change.
User-visible CLI output: see the smoke run under Validation.
Remaining proof gaps: several existing setup/registration suites fail on this
Windows + Bun machine on the base commit too (POSIX path expectations, symlink
creation needing privileges, process.execPath alignment). Those suites were
not proven locally and rely on CI.

Validation performed

All local validation ran under Bun 1.4.2 on Windows x64 without Node.js or
npm installed. CI covers Node.

bun --bun run compile — succeeded.
bun --bun run artifacts:skills, artifacts:product-catalog,
artifacts:error-schema, artifacts:mcp-catalog, artifacts:managed-evidence —
succeeded (needed by docs checks).
bun --bun node_modules/vitest/vitest.mjs run tests/boundary/filesystem/clientRegistrationFields.test.ts — 12/12 passed.
bun --bun node_modules/vitest/vitest.mjs run tests/boundary/filesystem/client tests/boundary/filesystem/omp tests/boundary/filesystem/pi tests/boundary/filesystem/qwen tests/boundary/filesystem/hermes tests/boundary/filesystem/setup tests/boundary/filesystem/windowsNpx tests/boundary/filesystem/gemini tests/acceptance/setup tests/unit/application
— branch: 50 failed / 200 passed / 4 skipped. Base (same command with the
change stashed): 50 failed / 187 passed / 4 skipped. The failing test names
are identical on both (Windows/Bun environment failures listed above). The 13
extra passes are the new tests.
The same new tests with base src/ — 12 failed, 1 passed (see above).
bun --bun run typecheck — passed.
bun --bun run lint — exit 0. No new findings; the existing max-lines
warning on ClientConfigurationDocument.ts was already there.
bun --bun node_modules/.bin/oxfmt --check on the six changed files — all formatted.
bun --bun run docs:check:built — passed. (docs:check itself refuses to
start without npm's node_modules/.package-lock.json.)
Real CLI smoke run (temp root; HOME, USERPROFILE, APPDATA,
LOCALAPPDATA pointed inside it; REA_IDA_MCP_CONFIG set to a temp JSON
file): seeded home/.omp/agent/mcp.json with the entry from the Problem
section, using a stale command/args.
- bun scripts\rea.mjs setup --client omp --yes → exit 0. Resulting entry:
```
"rea": {
  "type": "stdio",
  "command": "C:\\Users\\<user>\\.bun\\bin\\bun.exe",
  "args": ["<worktree>\\scripts\\rea.mjs", "mcp"],
  "env": { "REA_ANALYSIS_PROVIDER": "ida", "REA_IDA_MCP_CONFIG": "<temp>\\ida-mcp.json" },
  "timeout": 0
}
```
  mcp.json.rea.backup equals the original file byte for byte.
- Second setup --client omp --yes → exit 0, plannedActions: [],
  appliedActions: [], and the file is byte-identical to the first run's output.
- bun scripts\rea.mjs doctor → registrations: - client: omp … state: aligned, remediation: null. Doctor exits 1 only because the placeholder IDA config
  ({}) is not a valid IDA MCP registration (ida-registration check), which
  has nothing to do with this change.

Compatibility, safety, and release

Breaking changes or migration steps: none. Entries that only contain REA's keys
produce the same output as before. Entries with user-added fields now keep them
instead of losing them.
Real Hopper/Ghidra, browser, or OS coverage: Windows x64 with Bun only. No
provider is exercised.
Package or release metadata impact: none.
Security, privacy, process, or containment review: setup still writes only the
rea entry, still backs up first and reads back. Remote credentials
(headers, bearer_token_env_var, oauth) on a stale entry are removed, not
carried into the local registration.

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1732 **Author:** [@xeropresence](https://github.com/xeropresence) **Created:** 10/11/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/setup-preserve-entry-fields` --- ### 📝 Commits (10+) - [`c136ba3`](https://github.com/morluto/rea/commit/c136ba35b63bcc5c50ef47ca8229eda8a8a125b6) fix(setup): preserve user fields on an existing REA client entry - [`768a2c4`](https://github.com/morluto/rea/commit/768a2c4167f8c09a79c3bb54f429d72a97453da7) fix(setup): drop stale Codex oauth_resource and disclose remote replacement - [`b576d83`](https://github.com/morluto/rea/commit/b576d838b025118eb135b071a0e58985935a49c6) fix(setup): disclose remote-key removal in the approval plan - [`887907c`](https://github.com/morluto/rea/commit/887907ccdcd820eda616c7547bf66f9409dadf59) fix(setup): drop stale Qwen tcp endpoints and name rewritten entry keys - [`d9d87df`](https://github.com/morluto/rea/commit/d9d87df32fdeccd073fb1d2ca068a4d1a2060104) fix(setup): drop non-boolean activation switches from retained entries - [`e5910e6`](https://github.com/morluto/rea/commit/e5910e69fbccc385353106fe1f8f697562045af5) fix(setup): retain only registration fields doctor can parse - [`2e9320f`](https://github.com/morluto/rea/commit/2e9320fcb449962a12ed9df4cd8d69b8cd0bdb86) refactor(setup): accept retained fields from the registration schema - [`a088312`](https://github.com/morluto/rea/commit/a088312c770e3ba62db766b3ef74e2f29dbba9cf) fix(setup): describe the inspected OpenCode registration dialect - [`6e4a431`](https://github.com/morluto/rea/commit/6e4a4312570b05f68060170f9f6dc1b14097e705) fix(setup): match retained fields to the client that writes them - [`6297d5f`](https://github.com/morluto/rea/commit/6297d5ff221e18f5971c436d10dd4270c186ba46) fix(setup): drop ZCode's enable: false from retained entries ### 📊 Changes **19 files changed** (+892 additions, -64 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+15 -0) 📝 `src/application/ClientConfigurationDocument.ts` (+145 -0) ➕ `src/application/ClientRegistrationShape.test.ts` (+27 -0) ➕ `src/application/ClientRegistrationShape.ts` (+81 -0) 📝 `src/application/ClientRegistrationStatus.ts` (+12 -22) 📝 `src/application/DshCordisPatch.ts` (+12 -0) 📝 `src/application/Setup.planning.test.ts` (+121 -0) 📝 `src/application/SetupClientConfiguration.ts` (+39 -30) 📝 `src/application/SetupPlan.ts` (+23 -5) 📝 `src/application/SetupTypes.ts` (+8 -1) 📝 `tests/boundary/filesystem/claudeDesktopClientConfiguration.test.ts` (+3 -2) 📝 `tests/boundary/filesystem/clientConfigurationBom.test.ts` (+4 -0) 📝 `tests/boundary/filesystem/clientConfigurationEnvironment.test.ts` (+1 -1) 📝 `tests/boundary/filesystem/clientConfigurationLayeredEnvironment.test.ts` (+3 -2) 📝 `tests/boundary/filesystem/clientConfigurationTransactions.test.ts` (+1 -0) ➕ `tests/boundary/filesystem/clientRegistrationFields.test.ts` (+343 -0) 📝 `tests/boundary/filesystem/dshClientConfiguration.test.ts` (+8 -0) 📝 `tests/boundary/filesystem/ompClientConfiguration.test.ts` (+45 -0) 📝 `tests/boundary/filesystem/piClientConfiguration.test.ts` (+1 -1) </details> ### 📄 Description ## Summary Re-running `rea setup` on a client that already has a `rea` server entry rewrote that entry from scratch. Environment overrides were carried over (since #1607), but every other field the user had added was lost. The visible case: an OMP entry with `"timeout": 0` (OMP's MCP request timeout; `0` turns it off, which long IDA analyses need) came back without `timeout`, so the next long request timed out. Setup now changes only the keys REA owns in its entry and keeps the rest. A second setup run makes no change, and `rea doctor` still reports the entry as `aligned`. No issue is linked; this was found while running REA under Bun with an IDA provider registration in OMP. ## Problem and expected behavior Smallest trigger (`~/.omp/agent/mcp.json`): ```json { "mcpServers": { "rea": { "type": "stdio", "command": "C:\\old\\bun.exe", "args": ["C:\\old\\rea.mjs", "mcp"], "env": { "REA_ANALYSIS_PROVIDER": "ida", "REA_IDA_MCP_CONFIG": "C:\\ida-mcp.json" }, "timeout": 0 } } } ``` `rea setup --client omp --yes` wrote `{type, command, args, env}`, without `timeout`. That breaks AGENTS.md's rule that configuration changes are additive. The setup plan already said "Existing server environment overrides are retained", so users had no reason to expect other fields to go. Expected: the new `command`/`args` replace the stale launcher, `env` is kept and merged as before, and `timeout` stays. ## Change and scope The desired entry is built in one place, `clientConfigurationDesired` (`src/application/SetupClientConfiguration.ts`). Setup writes it, and both alignment checks (setup preflight, `--dry-run`, and `clientConfigurationAligned`) compare against it. That function now passes REA's fresh entry through a new `retainClientRegistrationFields(dialect, existing, registration)` in `ClientConfigurationDocument.ts`. Because the merge happens there, every writer (JSON/JSONC, Codex TOML, Grok TOML, Hermes YAML, OpenCode V1/V2) and every "is it current?" check sees the same merged entry, so setup stays idempotent. Rules: - **REA-owned keys get REA's values:** the launch keys `command`, `args`, `type`, `transport`, `env`/`environment`, plus anything REA's entry sets for that dialect (`tools` for Copilot CLI, `enabled: true` for OpenCode V1/Command Code/Hermes, `startup_timeout_sec` for Codex and Grok Build). If REA's new entry leaves out a launch key, the existing one is removed. For example, a stale `type: "http"` is removed from a JSON entry, and an empty env map is not left behind. - **Keys that contradict a local stdio entry are removed:** `url`, `httpUrl`, `serverUrl`, `headers`, `http_headers`, `env_http_headers`, `bearer_token_env_var`, `oauth`. Keeping a stale `url` beside the new `command` could make a client pick the remote transport or reject the entry. - **Entry-level off switches are removed:** `enabled: false`, and `disabled: true` except on Grok Build. Setup's job is an active registration, and it already removes `rea` from OMP's `disabledServers` and Grok's `disabled_mcp_servers` for the same reason. Grok's entry-level `disabled` is kept because registration status does not treat it as an off switch for Grok either. - **Everything else is kept:** e.g. OMP/Pi `timeout`, `enabled: true`, `instructions`; Codex `tool_timeout_sec`, `enabled_tools`; Gemini/Cursor `timeout`, `trust`; Hermes `timeout`, `connect_timeout`. Existing key order is kept, and new REA keys are added at the end. - **Remote entries are replaced whole:** if the existing `rea` entry has no `command`, it is a remote server, and setup replaces it entirely as before. Merging its remote-only fields into a local entry would be wrong. - **Legacy OpenCode V1 → V2 migration:** only the entry in the table being written is used as the base. A V1 `mcp.rea` entry that moves into a native `mcp.servers` table keeps only its environment (as before), because its other fields use the V1 shape. Every writable dialect is covered. Clients with format `unsupported` (manual registration) have no entry for setup to merge, so nothing changes for them. Not included: preserving comments inside the `rea` entry itself (the JSONC writer still replaces the entry value as one unit; comments elsewhere in the file were already kept), and any change to uninstall. ## Contract and boundary impact - Semantic owner and earliest changed stage: `clientConfigurationDesired` in `src/application/SetupClientConfiguration.ts`, using the new `retainClientRegistrationFields` in `src/application/ClientConfigurationDocument.ts`. - CLI and MCP/tool-catalog contract: no new commands or flags. The setup plan's client detail now also says that other fields on REA's existing entry are retained (the existing "Existing server environment overrides are retained" wording is unchanged). - Provider, bridge, target-format, or platform compatibility: applies to every writable client dialect; no provider change. - Evidence, artifact, provenance, or reconstruction contract: not applicable. - Process execution, authorization, cleanup, or containment impact: none. Writes still go through the same backup, atomic-replace, and read-back path. - Generated metadata, package, or installation impact: none. `docs/installation.md` describes which keys setup rewrites, removes, and keeps. ## Evidence and regression coverage - Tests added or updated: - `tests/boundary/filesystem/clientRegistrationFields.test.ts` (new): one case for each writable dialect (Cursor JSON, VS Code, OMP, Pi, Copilot CLI, Command Code, OpenCode V1, OpenCode V2, Codex TOML, Grok Build TOML, Hermes YAML). It seeds an entry with a stale command, env, dialect-specific user fields, a stale `url` and `enabled: false`, then runs `inspectClientConfiguration` → `update`, `configureClientConfiguration` → `configured`. It checks that the entry equals REA's entry plus the user fields, that `clientConfigurationAligned` → `true` and inspect → `already_current`, and that a second configure → `unchanged` with byte-identical file text. One more case checks that a remote entry (no `command`) is still replaced whole. - `tests/boundary/filesystem/ompClientConfiguration.test.ts`: the reported OMP case with `timeout: 0` and an env override. It checks setup output, second-run byte identity, and `readClientRegistrationStatuses` → `aligned`. - Base reproduction: with `src/` checked out from the base commit (0ecf3f24), all 12 field-retention tests fail (11 dialect cases plus the OMP timeout case), because the extra fields are dropped. The remote-entry test passes on base, since that behavior did not change. - User-visible CLI output: see the smoke run under Validation. - Remaining proof gaps: several existing setup/registration suites fail on this Windows + Bun machine on the base commit too (POSIX path expectations, symlink creation needing privileges, `process.execPath` alignment). Those suites were not proven locally and rely on CI. ## Validation performed All local validation ran under **Bun 1.4.2 on Windows x64 without Node.js or npm installed**. CI covers Node. - `bun --bun run compile` — succeeded. - `bun --bun run artifacts:skills`, `artifacts:product-catalog`, `artifacts:error-schema`, `artifacts:mcp-catalog`, `artifacts:managed-evidence` — succeeded (needed by docs checks). - `bun --bun node_modules/vitest/vitest.mjs run tests/boundary/filesystem/clientRegistrationFields.test.ts` — 12/12 passed. - `bun --bun node_modules/vitest/vitest.mjs run tests/boundary/filesystem/client tests/boundary/filesystem/omp tests/boundary/filesystem/pi tests/boundary/filesystem/qwen tests/boundary/filesystem/hermes tests/boundary/filesystem/setup tests/boundary/filesystem/windowsNpx tests/boundary/filesystem/gemini tests/acceptance/setup tests/unit/application` — branch: 50 failed / 200 passed / 4 skipped. Base (same command with the change stashed): 50 failed / 187 passed / 4 skipped. The failing test names are identical on both (Windows/Bun environment failures listed above). The 13 extra passes are the new tests. - The same new tests with base `src/` — 12 failed, 1 passed (see above). - `bun --bun run typecheck` — passed. - `bun --bun run lint` — exit 0. No new findings; the existing `max-lines` warning on `ClientConfigurationDocument.ts` was already there. - `bun --bun node_modules/.bin/oxfmt --check` on the six changed files — all formatted. - `bun --bun run docs:check:built` — passed. (`docs:check` itself refuses to start without npm's `node_modules/.package-lock.json`.) - Real CLI smoke run (temp root; `HOME`, `USERPROFILE`, `APPDATA`, `LOCALAPPDATA` pointed inside it; `REA_IDA_MCP_CONFIG` set to a temp JSON file): seeded `home/.omp/agent/mcp.json` with the entry from the Problem section, using a stale `command`/`args`. - `bun scripts\rea.mjs setup --client omp --yes` → exit 0. Resulting entry: ```json "rea": { "type": "stdio", "command": "C:\\Users\\<user>\\.bun\\bin\\bun.exe", "args": ["<worktree>\\scripts\\rea.mjs", "mcp"], "env": { "REA_ANALYSIS_PROVIDER": "ida", "REA_IDA_MCP_CONFIG": "<temp>\\ida-mcp.json" }, "timeout": 0 } ``` `mcp.json.rea.backup` equals the original file byte for byte. - Second `setup --client omp --yes` → exit 0, `plannedActions: []`, `appliedActions: []`, and the file is byte-identical to the first run's output. - `bun scripts\rea.mjs doctor` → `registrations: - client: omp … state: aligned, remediation: null`. Doctor exits 1 only because the placeholder IDA config (`{}`) is not a valid IDA MCP registration (`ida-registration` check), which has nothing to do with this change. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Entries that only contain REA's keys produce the same output as before. Entries with user-added fields now keep them instead of losing them. - Real Hopper/Ghidra, browser, or OS coverage: Windows x64 with Bun only. No provider is exercised. - Package or release metadata impact: none. - Security, privacy, process, or containment review: setup still writes only the `rea` entry, still backs up first and reads back. Remote credentials (`headers`, `bearer_token_env_var`, `oauth`) on a stale entry are removed, not carried into the local registration. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-31 00:55:00 +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#4782

No description provided.

Rows
Columns