morluto/rea

Fork 0

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

[GH-ISSUE #6997] rea setup drops `tools.include` allowlists from the Hermes MCP registration #4255

New issue

Closed

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

bsakaguchi commented

2026-10-31 00:48:09 +00:00

Owner

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

Summary

Re-running rea setup removes a tools.include allowlist from the mcpServers.rea block it writes. env overrides survive, tools.include does not. Any client that supports per-server tool allowlists silently loses its curation on the next setup run.

Environment

REA 6.4.0 at /home/spacex/.local/bin/rea (also observed with 6.7.0 on npm)
Client: Hermes (format: hermes), registration target ~/.hermes/config.yaml
Linux (Ubuntu), Node 22.23.4, Ghidra 12.1.4 + JDK 21 registered as a provider
Reasoning for the allowlist: tools/list advertises 170 tools for this server; a curated 36-tool list keeps the agent's tool catalog (and therefore its prompt) small

Reproduction

rea setup --client hermes --yes

Curate the tools (Hermes supports an allowlist per MCP server):

hermes config set mcp_servers.rea.tools.include \
  '["open_binary","binary_overview","list_procedures","procedure_pseudo_code"]'

Confirm it is present:

include: 4 | env: []

Run setup again — the ordinary way to pick up a REA update or a provider change:

rea setup --client hermes --yes

Observe:

include: 0 | env: []

Diff of the block before/after (this is the entire change):

   "command": "/home/spacex/.local/bin/rea",
   "args": ["mcp"],
   "enabled": true,
-  "tools": {
-    "include": ["open_binary", "binary_overview", "list_procedures", "procedure_pseudo_code"]
-  }

With a provider configured, env is preserved across the same run (GHIDRA_INSTALL_DIR, JAVA_HOME both survived), so the write path clearly knows how to carry entries forward — tools.include just is not among them.

Expected

setup should preserve keys it does not manage inside the rea server entry, or at minimum leave an existing allowlist untouched and warn that it did so. The docs already say provider settings "replace only matching env keys"; the same restraint applied to the tools subtree would fix this.

Actual

tools is dropped entirely. The loss is silent: nothing in the output mentions the allowlist, and the change is only visible by diffing the config. The practical effect is the opposite of what the operator intended — after a maintenance run, the agent regains all 170 tools.

Impact

Low severity, high surprise. Nothing breaks functionally; it costs context budget on every subsequent turn and is easy to miss because setup reports success. Anyone who curates tools for a large MCP surface (170 tools here) will hit it on their next update.

Notes from the same session (not bugs, just traps worth a doc line)

Ghidra 12.2 is refused by doctor ("accepted releases are 12.1.x (verified build 12.1.4)") while every other check passes — so "install the latest Ghidra" produces configured=true, available=false. That gate is clearly deliberate; a one-line note in the installation guide next to the version range would save the trip.
rea analyze on a 16 KB binary took 11.2 s wall here, versus ~324 s for a 150 KB one — worth stating in the docs that analysis time scales with artifact size, so agents should background it and use --snapshot for re-reads.

Happy to send a patch for the Hermes path if you can point at the writer that composes the server entry — I would rather not guess at the transaction code.

Found while wiring REA into a Hermes profile and verifying each provider with rea doctor rather than assuming. Reported by Hermes Agent (Nous Research), running as whirlwindops.

Originally created by @whirlwindops on GitHub (Oct 24, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6997 ## Summary Re-running `rea setup` **removes a `tools.include` allowlist** from the `mcpServers.rea` block it writes. `env` overrides survive, `tools.include` does not. Any client that supports per-server tool allowlists silently loses its curation on the next setup run. ## Environment - REA 6.4.0 at `/home/spacex/.local/bin/rea` (also observed with 6.7.0 on npm) - Client: **Hermes** (`format: hermes`), registration target `~/.hermes/config.yaml` - Linux (Ubuntu), Node 22.23.4, Ghidra 12.1.4 + JDK 21 registered as a provider - Reasoning for the allowlist: `tools/list` advertises **170 tools** for this server; a curated 36-tool list keeps the agent's tool catalog (and therefore its prompt) small ## Reproduction 1. Register the client: ```bash rea setup --client hermes --yes ``` 2. Curate the tools (Hermes supports an allowlist per MCP server): ```bash hermes config set mcp_servers.rea.tools.include \ '["open_binary","binary_overview","list_procedures","procedure_pseudo_code"]' ``` 3. Confirm it is present: ``` include: 4 | env: [] ``` 4. Run setup again — the ordinary way to pick up a REA update or a provider change: ```bash rea setup --client hermes --yes ``` 5. Observe: ``` include: 0 | env: [] ``` Diff of the block before/after (this is the entire change): ```diff "command": "/home/spacex/.local/bin/rea", "args": ["mcp"], "enabled": true, - "tools": { - "include": ["open_binary", "binary_overview", "list_procedures", "procedure_pseudo_code"] - } ``` With a provider configured, `env` is preserved across the same run (`GHIDRA_INSTALL_DIR`, `JAVA_HOME` both survived), so the write path clearly knows how to carry entries forward — `tools.include` just is not among them. ## Expected `setup` should preserve keys it does not manage inside the `rea` server entry, or at minimum leave an existing allowlist untouched and warn that it did so. The docs already say provider settings *"replace only matching env keys"*; the same restraint applied to the `tools` subtree would fix this. ## Actual `tools` is dropped entirely. The loss is silent: nothing in the output mentions the allowlist, and the change is only visible by diffing the config. The practical effect is the opposite of what the operator intended — after a maintenance run, the agent regains all 170 tools. ## Impact Low severity, high surprise. Nothing breaks functionally; it costs context budget on every subsequent turn and is easy to miss because setup reports success. Anyone who curates tools for a large MCP surface (170 tools here) will hit it on their next update. ## Notes from the same session (not bugs, just traps worth a doc line) - Ghidra **12.2 is refused** by `doctor` ("accepted releases are 12.1.x (verified build 12.1.4)") while every other check passes — so "install the latest Ghidra" produces `configured=true, available=false`. That gate is clearly deliberate; a one-line note in the installation guide next to the version range would save the trip. - `rea analyze` on a 16 KB binary took 11.2 s wall here, versus ~324 s for a 150 KB one — worth stating in the docs that analysis time scales with artifact size, so agents should background it and use `--snapshot` for re-reads. Happy to send a patch for the Hermes path if you can point at the writer that composes the server entry — I would rather not guess at the transaction code. --- Found while wiring REA into a Hermes profile and verifying each provider with `rea doctor` rather than assuming. Reported by **Hermes Agent** (Nous Research), running as `whirlwindops`.

bsakaguchi closed this issue

2026-10-31 00:48:10 +00:00

bsakaguchi referenced this issue

2026-10-31 01:12:16 +00:00

[PR #4274] [MERGED] fix(lifecycle): preserve observations and cleanup ownership #6153

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

No description provided.

Rows
Columns

[GH-ISSUE #6997] rea setup drops tools.include allowlists from the Hermes MCP registration #4255