morluto/rea

Fork 0

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

[GH-ISSUE #5512] [Bug] Pinned mcpclaude prefix in a Claude Code fork hides REA from the model while doctor stays green #3354

New issue

Open

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

bsakaguchi commented

2026-10-31 00:39:28 +00:00

Owner

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

Before submitting:

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Observed behavior

While debugging REA usage through a Claude Code flavored CLI (2026-10-20), rea setup --client claude_code wrote the registration to ~/.claude.json and rea doctor reported registration:claude_code healthy, but the client never exposed REA's ~200 tools under the documented mcp__rea__* names. Every MCP server configured in that client, REA included, surfaced as mcp__claude__<tool>, the prefix pinned to the product name instead of the registered server key. Approving a REA tool interactively added mcp__claude__* to the allowlist in ~/.claude/settings.json, a pattern that grants permission to all of that client's MCP servers rather than to REA, and matches nothing in REA's docs or skill.

The client was OneKeyHQ/claude-code, an unofficial mirror of the deobfuscated leaked Claude Code source. That repo was removed during the investigation in the DMCA takedown sweep of leaked Claude Code forks and 404s on web and API. The local build and its config files were also subsequently deleted from the machine, so the client-side part cannot be rerun or linked. Observed-vs-source-derived labeling below follows that constraint.

Reproduction

What was actually run on 2026-10-20; no longer runnable:

Installed REA 6.5.0 from npm, ran rea setup --client claude_code --yes, inspected the diff: registration landed in mcpServers in ~/.claude.json.
Started the fork build (claude-code-isolated) and listed its connected MCP tools: REA tools appeared as mcp__claude__binary_session and similar; unrelated servers carried the same pinned prefix.
Approved one tool; mcp__claude__* appeared in the allow list in ~/.claude/settings.json. rea doctor stayed healthy throughout.

The REA-side observations above remain re-derivable from REA source. The client-side prefix behavior is reported from reading the fork's source during the session; that source is gone from GitHub and from my machine, so I cannot link it to a revision.

Expected behavior

The docs state clients expose tools as mcp__rea__<tool_name> (docs/client-configuration.md:401), and the bundled skill points the agent at those names. That contract is client-controlled: REA cannot enforce it, and I could find nothing that notices when it is broken. The expectation that the registered server key becomes the prefix holds on official Claude Code per its documented naming convention; I did not re-verify that on the current official CLI here.

Impact and scope

REA was unusable through that client while every REA-side check passed; the agent was pointed at mcp__rea__* names that do not exist in the client. The approval flow left a blanket allow entry covering every MCP server that client registers, in the shared ~/.claude/settings.json. The shared ~/.claude.json means REA's registration loads into every Claude-flavored binary on the machine, including forks. Observed once. Other forks untested; prevalence of pinned-prefix behavior in forked clients is unknown.

REA version

6.5.0 (npm). Source claims re-checked against 6.7.0, commit 67384b23e.

Runtime and platform

Node 24.18, Arch Linux x86_64.

Target and artifact context

Not applicable.

Area

MCP or agent integration

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Source, 67384b23e: src/identity.ts:14 registers the server key "rea". mcp__claude__ appears nowhere in REA's src or docs, so the naming on the REA side is clean.
Source, 67384b23e: src/application/Doctor.ts:417-419 emits registration:<client> from config-file validity; no check consults the tool names a client actually exposes, or the allow entries in ~/.claude/settings.json.
Session notes, 2026-10-20: ~/.claude.json held the rea server entry; ~/.claude/settings.json held the mcp__claude__* allow entry; the client's tool listing showed mcp__claude__binary_session. These files are since deleted from the machine along with the client.
Missing evidence: the fork's source and binary are unavailable (repo DMCA-removed, local copies deleted), so the client-side claim cannot be linked to a revision.

Typed outcome or recovery expected

When a registration file is valid but the client exposes tools under a prefix that never mentions rea, something should say so. For example, doctor could inspect allow entries in ~/.claude/settings.json and, when a blanket mcp__<prefix>__* entry exists that does not cover REA's registered name, report it as config drift with a narrowing suggestion.

Analysis or suspected cause

Source-derived: REA assumes clients derive the tool prefix from the registered server key. That holds for the clients REA verifies against. A fork that hardcodes the prefix breaks the assumption silently and completely. If this class is worth covering: a troubleshooting note in the tool-naming docs that the prefix is client-chosen and worth confirming against the client's own tool listing, plus the settings.json finding above.

Originally created by @lindestad on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5512 Before submitting: - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Observed behavior While debugging REA usage through a Claude Code flavored CLI (2026-10-20), `rea setup --client claude_code` wrote the registration to `~/.claude.json` and `rea doctor` reported `registration:claude_code` healthy, but the client never exposed REA's ~200 tools under the documented `mcp__rea__*` names. Every MCP server configured in that client, REA included, surfaced as `mcp__claude__<tool>`, the prefix pinned to the product name instead of the registered server key. Approving a REA tool interactively added `mcp__claude__*` to the allowlist in `~/.claude/settings.json`, a pattern that grants permission to all of that client's MCP servers rather than to REA, and matches nothing in REA's docs or skill. The client was OneKeyHQ/claude-code, an unofficial mirror of the deobfuscated leaked Claude Code source. That repo was removed during the investigation in the DMCA takedown sweep of leaked Claude Code forks and 404s on web and API. The local build and its config files were also subsequently deleted from the machine, so the client-side part cannot be rerun or linked. Observed-vs-source-derived labeling below follows that constraint. ### Reproduction What was actually run on 2026-10-20; no longer runnable: 1. Installed REA 6.5.0 from npm, ran `rea setup --client claude_code --yes`, inspected the diff: registration landed in `mcpServers` in `~/.claude.json`. 2. Started the fork build (`claude-code-isolated`) and listed its connected MCP tools: REA tools appeared as `mcp__claude__binary_session` and similar; unrelated servers carried the same pinned prefix. 3. Approved one tool; `mcp__claude__*` appeared in the allow list in `~/.claude/settings.json`. `rea doctor` stayed healthy throughout. The REA-side observations above remain re-derivable from REA source. The client-side prefix behavior is reported from reading the fork's source during the session; that source is gone from GitHub and from my machine, so I cannot link it to a revision. ### Expected behavior The docs state clients expose tools as `mcp__rea__<tool_name>` (`docs/client-configuration.md:401`), and the bundled skill points the agent at those names. That contract is client-controlled: REA cannot enforce it, and I could find nothing that notices when it is broken. The expectation that the registered server key becomes the prefix holds on official Claude Code per its documented naming convention; I did not re-verify that on the current official CLI here. ### Impact and scope REA was unusable through that client while every REA-side check passed; the agent was pointed at `mcp__rea__*` names that do not exist in the client. The approval flow left a blanket allow entry covering every MCP server that client registers, in the shared `~/.claude/settings.json`. The shared `~/.claude.json` means REA's registration loads into every Claude-flavored binary on the machine, including forks. Observed once. Other forks untested; prevalence of pinned-prefix behavior in forked clients is unknown. ### REA version 6.5.0 (npm). Source claims re-checked against 6.7.0, commit 67384b23e. ### Runtime and platform Node 24.18, Arch Linux x86_64. ### Target and artifact context Not applicable. ### Area MCP or agent integration ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence - Source, 67384b23e: `src/identity.ts:14` registers the server key `"rea"`. `mcp__claude__` appears nowhere in REA's src or docs, so the naming on the REA side is clean. - Source, 67384b23e: `src/application/Doctor.ts:417-419` emits `registration:<client>` from config-file validity; no check consults the tool names a client actually exposes, or the allow entries in `~/.claude/settings.json`. - Session notes, 2026-10-20: `~/.claude.json` held the `rea` server entry; `~/.claude/settings.json` held the `mcp__claude__*` allow entry; the client's tool listing showed `mcp__claude__binary_session`. These files are since deleted from the machine along with the client. - Missing evidence: the fork's source and binary are unavailable (repo DMCA-removed, local copies deleted), so the client-side claim cannot be linked to a revision. ### Typed outcome or recovery expected When a registration file is valid but the client exposes tools under a prefix that never mentions `rea`, something should say so. For example, doctor could inspect allow entries in `~/.claude/settings.json` and, when a blanket `mcp__<prefix>__*` entry exists that does not cover REA's registered name, report it as config drift with a narrowing suggestion. ### Analysis or suspected cause Source-derived: REA assumes clients derive the tool prefix from the registered server key. That holds for the clients REA verifies against. A fork that hardcodes the prefix breaks the assumption silently and completely. If this class is worth covering: a troubleshooting note in the tool-naming docs that the prefix is client-chosen and worth confirming against the client's own tool listing, plus the settings.json finding above.

bsakaguchi referenced this issue

2026-10-31 00:47:35 +00:00

[GH-ISSUE #6854] [Bug] Obligation ledger verifies a changed owner using proof for the previous implementation #4193

bsakaguchi referenced this issue

2026-10-31 01:10:21 +00:00

[PR #3802] [CLOSED] fix(reconstruction): evaluate declared dependency closure and risks #5907

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

No description provided.

Rows
Columns

[GH-ISSUE #5512] [Bug] Pinned mcp__claude__ prefix in a Claude Code fork hides REA from the model while doctor stays green #3354