morluto/rea

Fork 0

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

[GH-ISSUE #3906] [Bug] shipped CLI aliases disagree about registration identity #1517

New issue

Closed

opened 2026-10-16 21:06:30 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-16 21:06:30 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3906

Before submitting

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

Area

Setup, packaging, or upgrade

Observed behavior

On POSIX, the shipped rea and rea-agents bin links can point to one package script, yet a registration created through one alias becomes stale to doctor through the other. Uninstall through the other alias retains that setup-created entry as foreign. These are two consumers of one registration-identity failure. The finding is source-derived; REA was not run.

CURRENT_ENTRYPOINT_PATH applies lexical resolve() to process.argv[1]. POSIX setup persists that bin-link spelling. The identity classifier compares resolved strings without resolving the links to their common script. The stored absolute rea path differs from the current absolute rea-agents path. Neither the package-runner branch nor the special bare rea branch applies. Doctor maps foreign identity to stale, and uninstall retains the entry before mutation.

An initial disposable Node premise check ran once per alias. Both executable symlinks targeted entry.mjs; the output below shows distinct argument paths and the same loaded module basename:

rea 0 {"argv1":"rea","url":"entry.mjs"}
rea-agents 0 {"argv1":"rea-agents","url":"entry.mjs"}

This establishes Node's entrypoint behavior only. No REA setup, doctor, uninstall, package installation, runtime output, or REA exit status was observed.

Reproduction

These steps are proposed and unexecuted. Use the baseline below, a supported Node runtime, and both POSIX bin links from one installed package. Resolve their absolute paths before changing the home directory. Run directly through those links, without npx or bunx, and without npm_command=exec, which selects a different registration path.

Create a fresh writable disposable home. Unset client/provider location overrides and create its .cursor/mcp.json with {"mcpServers":{}}. Use that same isolated home and environment for every command.
Through the absolute rea bin link, run setup --client cursor --skill=false --yes --json. Setup persists that absolute command with arguments ["mcp"]. Explicit client selection and approval permit this configuration write; skill installation is disabled. Do not pass --install-hopper; Hopper installation is not selected.
Through the absolute rea-agents link, run doctor --client cursor --json. The traced result is stale. Through the original rea link, the same command follows the aligned branch.
Through rea-agents, run uninstall --json. The traced result retains the Cursor entry with detail The rea-named registration is not REA-owned. Uninstall through the original rea link reaches ordinary removal instead.

Expected behavior

Both advertised commands should recognize a registration created by this installation. Changing the CLI alias must preserve readiness and ownership for that unchanged registration. Uninstall should remove the setup-created REA entry and preserve unrelated configuration. Both public bin names point to the same script, and installation documentation promises removal of REA-owned registrations.

Impact and scope

Impact level: P2
Assessment status: supported
Impact basis: Switching between public aliases produces false readiness and leaves a setup-created registration during uninstall. Scope is bounded to direct POSIX registrations whose stored alias differs from the invocation.

REA version

Reviewed release: rea-agents@6.5.0, revision 3b79af28e80785afce9f5998d8f03289402a1847. The source review also compared fetched main at cf0a38ad9774ee9acff3164052688f7a58a1c72c and found the relevant identity behavior unchanged. The premise check used Node v26.10.0 on Darwin arm64. Windows and package-runner registrations are outside scope. No last-known-good release was established.

Runtime and platform

REA runtime reproduction was not run. Runtime and platform details for any smaller premise checks are recorded in the version/environment field above. Real-provider versions and end-to-end output are NOT_ENOUGH_INFO because no provider was launched.

Target and artifact context

Direct POSIX launcher registration in Cursor's ordinary JSON MCP configuration; both bin links belong to one installation.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Expected source: package.json:40-43 declares both bins; src/application/SupportedClients.ts:511-516 supports Cursor JSON; docs/installation.md:350-364 documents owned-registration removal and unrelated-data preservation.
Failure source: src/application/ClientRegistrationIdentity.ts:141-185 compares lexical paths; src/process/CurrentEntrypointPath.ts:3-11, src/application/ClientRegistrationStatus.ts:234-247,287-299, and src/application/Uninstall.ts:453-464 establish the entrypoint, stale status, and retention.
Evidence provenance: static
Local verification: static-proof
Reproduction completeness: complete

The initial Node observation separately supports the symlink-entrypoint premise. REA runtime reproduction was not run; this draft records the public-path proof and its guards.

The public path is scripts/rea.mjs:67-113 → src/cli.ts:98-100 → src/cli/setupCommands.ts:49-100,207-223. SetupHost.ts:62-100 selects [entrypointPath, "mcp"] on POSIX without a package runner; ordinary executable invocation supplies the required entrypoint, and MSIX is inapplicable. SetupPlan.ts:139-162 admits the explicit client and its writable ordinary JSON file. Setup.ts:327-337 → SetupClients.ts:42-46 → SetupHost.ts:251-261 → SetupClientConfiguration.ts:650-696 → ClientConfigurationDocument.ts:1437-1442,1505-1510 preserves the command through backup, write, and readback. These filenames are under src/application/.

Doctor's handler is setupCommands.ts:122-133. Doctor.ts:577-582 reads statuses with the current entrypoint. ClientRegistrationStatus.ts:137-169 admits the newly written valid configuration: detection evidence exists, activation is enabled, arguments parse, Cursor has no special transport/timeout requirement, and no version drift applies. Its identity call reaches the cited stale branch; :359-367 accepts the same-alias control. Uninstall's handler is setupCommands.ts:143-168; Uninstall.ts:232-270,402-432,557-574 reads the same entry, parses ownership through the same predicate, and reaches retention. Missing providers, malformed JSON, and filesystem failures are unnecessary.

Typed outcome or recovery expected

Using the same isolated setup, doctor through the alternate alias must report aligned and uninstall must remove the REA entry while preserving an unrelated fixture server. Reverse the aliases as a symmetric check. Keep same-alias and distinct-launcher controls so restoration preserves ownership discrimination. These checks are proposed, not executed.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: Switching between public aliases produces false readiness and leaves a setup-created registration during uninstall. Scope is bounded to direct POSIX registrations whose stored alias differs from the invocation.
Workaround status: available
Workaround basis: Invoke doctor or uninstall through the absolute command already stored in the registration. The traced identical-path branch accepts it and reaches removal without source changes or unrelated-data deletion. REA execution of this workaround was not run.

Originally created by @coygeek on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3906 ## 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. ## Area Setup, packaging, or upgrade ## Observed behavior On POSIX, the shipped `rea` and `rea-agents` bin links can point to one package script, yet a registration created through one alias becomes stale to doctor through the other. Uninstall through the other alias retains that setup-created entry as foreign. These are two consumers of one registration-identity failure. The finding is source-derived; REA was not run. `CURRENT_ENTRYPOINT_PATH` applies lexical `resolve()` to `process.argv[1]`. POSIX setup persists that bin-link spelling. The identity classifier compares resolved strings without resolving the links to their common script. The stored absolute `rea` path differs from the current absolute `rea-agents` path. Neither the package-runner branch nor the special bare `rea` branch applies. Doctor maps foreign identity to stale, and uninstall retains the entry before mutation. An initial disposable Node premise check ran once per alias. Both executable symlinks targeted `entry.mjs`; the output below shows distinct argument paths and the same loaded module basename: ```text rea 0 {"argv1":"rea","url":"entry.mjs"} rea-agents 0 {"argv1":"rea-agents","url":"entry.mjs"} ``` This establishes Node's entrypoint behavior only. No REA setup, doctor, uninstall, package installation, runtime output, or REA exit status was observed. ## Reproduction These steps are proposed and unexecuted. Use the baseline below, a supported Node runtime, and both POSIX bin links from one installed package. Resolve their absolute paths before changing the home directory. Run directly through those links, without `npx` or `bunx`, and without `npm_command=exec`, which selects a different registration path. 1. Create a fresh writable disposable home. Unset client/provider location overrides and create its `.cursor/mcp.json` with `{"mcpServers":{}}`. Use that same isolated home and environment for every command. 2. Through the absolute `rea` bin link, run `setup --client cursor --skill=false --yes --json`. Setup persists that absolute command with arguments `["mcp"]`. Explicit client selection and approval permit this configuration write; skill installation is disabled. Do not pass `--install-hopper`; Hopper installation is not selected. 3. Through the absolute `rea-agents` link, run `doctor --client cursor --json`. The traced result is stale. Through the original `rea` link, the same command follows the aligned branch. 4. Through `rea-agents`, run `uninstall --json`. The traced result retains the Cursor entry with detail `The rea-named registration is not REA-owned.` Uninstall through the original `rea` link reaches ordinary removal instead. ## Expected behavior Both advertised commands should recognize a registration created by this installation. Changing the CLI alias must preserve readiness and ownership for that unchanged registration. Uninstall should remove the setup-created REA entry and preserve unrelated configuration. Both public bin names point to the same script, and installation documentation promises removal of REA-owned registrations. ## Impact and scope - Impact level: P2 - Assessment status: supported - Impact basis: Switching between public aliases produces false readiness and leaves a setup-created registration during uninstall. Scope is bounded to direct POSIX registrations whose stored alias differs from the invocation. ## REA version Reviewed release: `rea-agents@6.5.0`, revision `3b79af28e80785afce9f5998d8f03289402a1847`. The source review also compared fetched main at `cf0a38ad9774ee9acff3164052688f7a58a1c72c` and found the relevant identity behavior unchanged. The premise check used Node `v26.10.0` on Darwin arm64. Windows and package-runner registrations are outside scope. No last-known-good release was established. ## Runtime and platform REA runtime reproduction was not run. Runtime and platform details for any smaller premise checks are recorded in the version/environment field above. Real-provider versions and end-to-end output are NOT_ENOUGH_INFO because no provider was launched. ## Target and artifact context Direct POSIX launcher registration in Cursor's ordinary JSON MCP configuration; both bin links belong to one installation. ## Interface CLI ## Earliest failure stage Setup or provider admission ## Relevant output or evidence - Expected source: [package.json:40-43](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/package.json#L40-L43) declares both bins; `src/application/SupportedClients.ts:511-516` supports Cursor JSON; [docs/installation.md:350-364](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/docs/installation.md#L350-L364) documents owned-registration removal and unrelated-data preservation. - Failure source: [src/application/ClientRegistrationIdentity.ts:141-185](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/application/ClientRegistrationIdentity.ts#L141-L185) compares lexical paths; `src/process/CurrentEntrypointPath.ts:3-11`, `src/application/ClientRegistrationStatus.ts:234-247,287-299`, and `src/application/Uninstall.ts:453-464` establish the entrypoint, stale status, and retention. - Evidence provenance: static - Local verification: static-proof - Reproduction completeness: complete The initial Node observation separately supports the symlink-entrypoint premise. REA runtime reproduction was not run; this draft records the public-path proof and its guards. The public path is `scripts/rea.mjs:67-113` → `src/cli.ts:98-100` → `src/cli/setupCommands.ts:49-100,207-223`. `SetupHost.ts:62-100` selects `[entrypointPath, "mcp"]` on POSIX without a package runner; ordinary executable invocation supplies the required entrypoint, and MSIX is inapplicable. `SetupPlan.ts:139-162` admits the explicit client and its writable ordinary JSON file. `Setup.ts:327-337` → `SetupClients.ts:42-46` → `SetupHost.ts:251-261` → `SetupClientConfiguration.ts:650-696` → `ClientConfigurationDocument.ts:1437-1442,1505-1510` preserves the command through backup, write, and readback. These filenames are under `src/application/`. Doctor's handler is `setupCommands.ts:122-133`. `Doctor.ts:577-582` reads statuses with the current entrypoint. `ClientRegistrationStatus.ts:137-169` admits the newly written valid configuration: detection evidence exists, activation is enabled, arguments parse, Cursor has no special transport/timeout requirement, and no version drift applies. Its identity call reaches the cited stale branch; `:359-367` accepts the same-alias control. Uninstall's handler is `setupCommands.ts:143-168`; `Uninstall.ts:232-270,402-432,557-574` reads the same entry, parses ownership through the same predicate, and reaches retention. Missing providers, malformed JSON, and filesystem failures are unnecessary. ## Typed outcome or recovery expected Using the same isolated setup, doctor through the alternate alias must report aligned and uninstall must remove the REA entry while preserving an unrelated fixture server. Reverse the aliases as a symmetric check. Keep same-alias and distinct-launcher controls so restoration preserves ownership discrimination. These checks are proposed, not executed. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Switching between public aliases produces false readiness and leaves a setup-created registration during uninstall. Scope is bounded to direct POSIX registrations whose stored alias differs from the invocation. - Workaround status: available - Workaround basis: Invoke doctor or uninstall through the absolute command already stored in the registration. The traced identical-path branch accepts it and reaches removal without source changes or unrelated-data deletion. REA execution of this workaround was not run.

bsakaguchi commented

2026-10-16 21:06:31 +00:00

Author

Owner

@Sandeep332005 commented on GitHub (Oct 15, 2026):

/assign

@Sandeep332005 commented on GitHub (Oct 15, 2026): /assign

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi closed this issue

2026-10-17 21:02:07 +00:00

bsakaguchi commented

2026-10-17 21:02:08 +00:00

Author

Owner

@panditshivam commented on GitHub (Oct 17, 2026):

Reproduced on current main (7aa4b98c9), macOS arm64 with Node 24.18.0: setup through rea succeeds, doctor through rea-agents reports config drift, and uninstall through that alias retains the setup-created entry. Same-alias doctor succeeds. This used a disposable home and both links to the same dispatcher; unrelated configuration stayed intact.

I see the earlier assignment request. Is an implementation already underway? I have not requested maintainer review; any submitted change will remain a draft for human review as required by CONTRIBUTING.md.

@panditshivam commented on GitHub (Oct 17, 2026): Reproduced on current main (7aa4b98c9), macOS arm64 with Node 24.18.0: setup through `rea` succeeds, doctor through `rea-agents` reports config drift, and uninstall through that alias retains the setup-created entry. Same-alias doctor succeeds. This used a disposable home and both links to the same dispatcher; unrelated configuration stayed intact. I see the earlier assignment request. Is an implementation already underway? I have not requested maintainer review; any submitted change will remain a draft for human review as required by CONTRIBUTING.md.

bsakaguchi referenced this issue

2026-10-17 21:11:52 +00:00

[PR #1483] [MERGED] feat(process): report bounded live capture progress #2921

bsakaguchi referenced this issue

2026-10-17 21:12:01 +00:00

[PR #1517] [MERGED] fix(javascript): expand an escaped receiver's methods once (#1495) #2937

bsakaguchi referenced this issue

2026-10-17 21:12:05 +00:00

[PR #1526] [MERGED] test(javascript): verify escaped receivers through CLI and MCP #2943

bsakaguchi referenced this issue

2026-10-17 21:12:08 +00:00

[PR #1529] [CLOSED] test(javascript): check #1495 growth rate instead of wall time #2945