[GH-ISSUE #7757] fix(setup): bind managed registrations to the selected installation #4633

New issue

Closed

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

bsakaguchi commented

2026-10-31 00:51:38 +00:00

Owner

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

Before submitting

Searched open and closed issues/PRs for related registration reports.
Removed credentials and private target data.

Area / interface / earliest stage

Setup and MCP registration; package acquisition before server startup.

Observed behavior

At 60bad9ed06, setup launched through npx/bunx still emits a package-resolving registration. Installed setup already binds an absolute runtime and entrypoint. Prewarming uses a neutral directory, but subsequent client launches resolve packages from their own working directory.

Executed reproduction

On Linux with Node 24.22.1/npm 11.16.0, an entirely local owned fixture supplied an inert same-name/same-version package in its project tree. Both normal npm exec and --global selected that project candidate while offline; an isolated-prefix control did not. The fixture only printed a fixed marker. This demonstrates why adding a registry/global flag alone would not establish package identity.

Expected behavior

Managed registrations should launch the already selected installation through its absolute runtime/entrypoint, retaining the analysis working directory and setup's package-source choice. Recognize legacy registrations for safe migration with backups and idempotence. Document recovery when a package-runner cache installation is removed.

Impact and scope

Managed setup registration and legacy-registration readiness. Manual package acquisition before REA starts remains owned by the package manager and caller. No remote payload or external compromise is claimed. Bun-specific resolution has not been reproduced; the proposed shared direct-launch path avoids a second resolution for either runner.

Evidence / runtime / target

SetupHost.setupRegistrationCommand, ClientRegistrationIdentity.packageRunnerRegistrationCommand, ClientRegistrationStatus; source revision above. Owned offline npm experiment: 1.646 s elapsed / 1.932 s CPU / 187.1 MiB sampled process-family RSS, two CPU affinity. Target: the installed REA MCP entrypoint; no analysis target execution.

Proposed verification

Real packed REA registration and MCP startup from a project with conflicting package-manager configuration; verify preserved cwd, no package-manager/project endpoint requests, legacy ownership/migration, backups and cache-removal recovery guidance. Native Windows coverage is proposed.

Originally created by @gensokyo-dev on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7757 ### Before submitting - [x] Searched open and closed issues/PRs for related registration reports. - [x] Removed credentials and private target data. ### Area / interface / earliest stage Setup and MCP registration; package acquisition before server startup. ### Observed behavior At 60bad9ed06474f5e4f2c09dce19f00f78591950e, setup launched through npx/bunx still emits a package-resolving registration. Installed setup already binds an absolute runtime and entrypoint. Prewarming uses a neutral directory, but subsequent client launches resolve packages from their own working directory. ### Executed reproduction On Linux with Node 24.22.1/npm 11.16.0, an entirely local owned fixture supplied an inert same-name/same-version package in its project tree. Both normal npm exec and `--global` selected that project candidate while offline; an isolated-prefix control did not. The fixture only printed a fixed marker. This demonstrates why adding a registry/global flag alone would not establish package identity. ### Expected behavior Managed registrations should launch the already selected installation through its absolute runtime/entrypoint, retaining the analysis working directory and setup's package-source choice. Recognize legacy registrations for safe migration with backups and idempotence. Document recovery when a package-runner cache installation is removed. ### Impact and scope Managed setup registration and legacy-registration readiness. Manual package acquisition before REA starts remains owned by the package manager and caller. No remote payload or external compromise is claimed. Bun-specific resolution has not been reproduced; the proposed shared direct-launch path avoids a second resolution for either runner. ### Evidence / runtime / target `SetupHost.setupRegistrationCommand`, `ClientRegistrationIdentity.packageRunnerRegistrationCommand`, `ClientRegistrationStatus`; source revision above. Owned offline npm experiment: 1.646 s elapsed / 1.932 s CPU / 187.1 MiB sampled process-family RSS, two CPU affinity. Target: the installed REA MCP entrypoint; no analysis target execution. ### Proposed verification Real packed REA registration and MCP startup from a project with conflicting package-manager configuration; verify preserved cwd, no package-manager/project endpoint requests, legacy ownership/migration, backups and cache-removal recovery guidance. Native Windows coverage is proposed.

bsakaguchi closed this issue

2026-10-31 00:51:38 +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#4633

No description provided.

Rows
Columns