[GH-ISSUE #439] [Bug] Bare npx setup can again select a stale local REA release #250

Closed
opened 2026-10-15 18:22:59 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Jul 26, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/439

Bug Description

REA's recommended setup command, npx rea-agents setup, can select an older project-local rea-agents dependency instead of the current npm release. The stale bootstrap then plans setup and version-pinned MCP registration using its own older product identity.

This behavior was previously reported in #291 and fixed by #292, which made rea-agents@latest canonical. PR #307 later restored the bare npx rea-agents setup entrypoint and the current main README recommends that form in the primary setup paths.

The persisted MCP launcher itself remains exact-version pinned. The regression is in selecting the package that runs setup and chooses that pinned version.

Steps to Reproduce

On Linux with Node.js 24.18.0 and npm 11.16.0:

repro=$(mktemp -d)
mkdir -p "$repro/project/subdir" "$repro/home-old/.codex" "$repro/home-new/.codex"
npm install --prefix "$repro/project" --no-save rea-agents@2.4.0
cd "$repro/project/subdir"

npx -y rea-agents --version
npx -y rea-agents@latest --version

HOME="$repro/home-old" \
  npx -y rea-agents setup \
  --client codex --skill=false --dry-run --json >"$repro/old-plan.json"

HOME="$repro/home-new" \
  npx -y rea-agents@latest setup \
  --client codex --skill=false --dry-run --json >"$repro/new-plan.json"

Observed on 2026-07-26, when npm latest was 2.5.0:

$ npx -y rea-agents --version
2.4.0

$ npx -y rea-agents@latest --version
2.5.0

The dry-run diagnostic reports also diverged:

old-plan.json: "cli_package_version": "2.4.0"
new-plan.json: "cli_package_version": "2.5.0"

The dry runs exited nonzero because the isolated homes had no configured analysis provider; package selection and plan diagnostics completed and produced the evidence above.

Expected Behavior

The recommended no-install setup command should not silently bootstrap an older ancestor or project-local dependency.

Either the documented command should explicitly request rea-agents@latest, or setup should detect that an unqualified npx invocation resolved a stale local release and stop before applying configuration. Explicit rea-agents@<version> invocations should remain available for intentional rollback.

Actual Behavior

npm treats the local 2.4.0 dependency as satisfying the unqualified npx rea-agents request. REA then runs the 2.4.0 setup implementation and uses that release's identity for the setup plan and eventual exact-version MCP registration.

Current unattended commands such as doctor and analyze already use rea-agents@latest; the inconsistency is concentrated in the recommended setup entrypoint.

Environment

  • REA versions: local 2.4.0; npm latest 2.5.0
  • Node.js version: 24.18.0
  • npm version: 11.16.0
  • OS: Linux 6.8.0-136-generic, x86_64
  • Hopper Disassembler version: not applicable
  • Target binary format: not applicable

Additional Context

  • MCP client: Codex
  • No target binary or provider startup is required to reproduce the bootstrap-version mismatch.
  • Related history: #291, #292, and #307.
Originally created by @morluto on GitHub (Jul 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/439 ## Bug Description REA's recommended setup command, `npx rea-agents setup`, can select an older project-local `rea-agents` dependency instead of the current npm release. The stale bootstrap then plans setup and version-pinned MCP registration using its own older product identity. This behavior was previously reported in #291 and fixed by #292, which made `rea-agents@latest` canonical. PR #307 later restored the bare `npx rea-agents setup` entrypoint and the current `main` README recommends that form in the primary setup paths. The persisted MCP launcher itself remains exact-version pinned. The regression is in selecting the package that runs setup and chooses that pinned version. ## Steps to Reproduce On Linux with Node.js 24.18.0 and npm 11.16.0: ```sh repro=$(mktemp -d) mkdir -p "$repro/project/subdir" "$repro/home-old/.codex" "$repro/home-new/.codex" npm install --prefix "$repro/project" --no-save rea-agents@2.4.0 cd "$repro/project/subdir" npx -y rea-agents --version npx -y rea-agents@latest --version HOME="$repro/home-old" \ npx -y rea-agents setup \ --client codex --skill=false --dry-run --json >"$repro/old-plan.json" HOME="$repro/home-new" \ npx -y rea-agents@latest setup \ --client codex --skill=false --dry-run --json >"$repro/new-plan.json" ``` Observed on 2026-07-26, when npm `latest` was 2.5.0: ```text $ npx -y rea-agents --version 2.4.0 $ npx -y rea-agents@latest --version 2.5.0 ``` The dry-run diagnostic reports also diverged: ```text old-plan.json: "cli_package_version": "2.4.0" new-plan.json: "cli_package_version": "2.5.0" ``` The dry runs exited nonzero because the isolated homes had no configured analysis provider; package selection and plan diagnostics completed and produced the evidence above. ## Expected Behavior The recommended no-install setup command should not silently bootstrap an older ancestor or project-local dependency. Either the documented command should explicitly request `rea-agents@latest`, or setup should detect that an unqualified npx invocation resolved a stale local release and stop before applying configuration. Explicit `rea-agents@<version>` invocations should remain available for intentional rollback. ## Actual Behavior npm treats the local 2.4.0 dependency as satisfying the unqualified `npx rea-agents` request. REA then runs the 2.4.0 setup implementation and uses that release's identity for the setup plan and eventual exact-version MCP registration. Current unattended commands such as doctor and analyze already use `rea-agents@latest`; the inconsistency is concentrated in the recommended setup entrypoint. ## Environment - REA versions: local 2.4.0; npm `latest` 2.5.0 - Node.js version: 24.18.0 - npm version: 11.16.0 - OS: Linux 6.8.0-136-generic, x86_64 - Hopper Disassembler version: not applicable - Target binary format: not applicable ## Additional Context - MCP client: Codex - No target binary or provider startup is required to reproduce the bootstrap-version mismatch. - Related history: #291, #292, and #307.
bsakaguchi 2026-10-15 18:22:59 +00:00
  • closed this issue
  • added the
    triage
    bug
    labels
Sign in to join this conversation.
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#250
No description provided.