[GH-ISSUE #3009] Registration pins rea-agents@4.1.0 while the CLI is 6.4.0, and the only remedy is rea setup #1053

New issue

Closed

opened 2026-10-15 18:30:41 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:30:41 +00:00

Owner

Originally created by @Selene0623 on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3009

~/.config/opencode/opencode.jsonc — written by rea setup — registers the server as:

"command": ["npx", "-y", "rea-agents@4.1.0", "mcp"]

The CLI that npx resolves today is 6.4.0, and doctor (6.4.0) reports:

registration:opencode   ok=false  config_drift  /home/selene/.config/opencode/opencode.jsonc
    remediation: "Run rea setup to refresh this registration, then restart the client."
skill:identity          ok=false  config_drift  installed skill 33, expected 37
identity.cli_package_version = "6.4.0"

Two problems:

The output never says the registration pins a version four minor releases behind the CLI, nor which
version it should carry. It prints the config path, not the registered command. Earlier reports
(#1338, #653) covered the opposite mistake — rea setup writing @latest, doctor calling it stale.
Both directions land on "run rea setup", which rewrites the user's global client config; that is not
something an agent should apply unattended, so the remediation should say so.
Doctor describes a catalogue the client is not running. identity.catalog.counts.mcp_tools = 170
and skill: expected 37 / installed 33 come from the CLI, while the registered server is 4.1.0. Any
conclusion an agent draws from doctor about available tools can be wrong for the server the client
actually loads.

Suggested:

Diff the registered version against the CLI version and print the exact command that would be written,
e.g. "registration pins rea-agents@4.1.0; this CLI is 6.4.0 — run rea setup to pin 6.4.0".
Either pin the registration to what rea setup is running (or its major), or record the resolved
registration version in doctor output so the drift is visible without reading the config by hand.

Environment: CachyOS (Arch), Node 26.11.1, npx install at
/home/selene/.npm/_npx/dea9475797100b20/node_modules/.bin/rea, client opencode, rea-agents 6.4.0 CLI with a
4.1.0 registration.

Originally created by @Selene0623 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3009 `~/.config/opencode/opencode.jsonc` — written by `rea setup` — registers the server as: "command": ["npx", "-y", "rea-agents@4.1.0", "mcp"] The CLI that npx resolves today is 6.4.0, and doctor (6.4.0) reports: registration:opencode ok=false config_drift /home/selene/.config/opencode/opencode.jsonc remediation: "Run rea setup to refresh this registration, then restart the client." skill:identity ok=false config_drift installed skill 33, expected 37 identity.cli_package_version = "6.4.0" Two problems: 1. **The output never says the registration pins a version four minor releases behind the CLI, nor which version it should carry.** It prints the config path, not the registered command. Earlier reports (#1338, #653) covered the opposite mistake — `rea setup` writing `@latest`, doctor calling it stale. Both directions land on "run rea setup", which rewrites the user's *global* client config; that is not something an agent should apply unattended, so the remediation should say so. 2. **Doctor describes a catalogue the client is not running.** `identity.catalog.counts.mcp_tools = 170` and `skill: expected 37 / installed 33` come from the CLI, while the registered server is 4.1.0. Any conclusion an agent draws from doctor about available tools can be wrong for the server the client actually loads. Suggested: 1. Diff the registered version against the CLI version and print the exact command that would be written, e.g. "registration pins rea-agents@4.1.0; this CLI is 6.4.0 — run rea setup to pin 6.4.0". 2. Either pin the registration to what `rea setup` is running (or its major), or record the resolved registration version in doctor output so the drift is visible without reading the config by hand. Environment: CachyOS (Arch), Node 26.11.1, npx install at `/home/selene/.npm/_npx/dea9475797100b20/node_modules/.bin/rea`, client opencode, rea-agents 6.4.0 CLI with a 4.1.0 registration.

bsakaguchi

2026-10-15 18:30:41 +00:00

closed this issue
added the
area: setup

enhancement
labels

bsakaguchi commented

2026-10-15 18:30:42 +00:00

Author

Owner

@XinyangWuEthz commented on GitHub (Oct 13, 2026):

Hi @Selene0623, thanks for the detailed report. I’m a first-time REA contributor and would like to work on a focused diagnostics fix here.
I’d start with a temporary OpenCode configuration reproducing the stale version pin, then improve doctor’s output to distinguish the configured package version from the current CLI version. I’d also clarify that the CLI’s catalogue does not establish which server version the client is currently running.
I’d keep this read-only: no automatic updates, configuration writes, or changes to the pinning policy, with regression tests for stale, matching, and unknown-version registrations.
@morluto, would you prefer this information in the existing diagnostic detail/remediation fields, or as structured fields as well? Is anyone already working on this? Otherwise, I’d be happy to take the focused fix. I haven’t reproduced it locally yet.

@XinyangWuEthz commented on GitHub (Oct 13, 2026): Hi @Selene0623, thanks for the detailed report. I’m a first-time REA contributor and would like to work on a focused diagnostics fix here. I’d start with a temporary OpenCode configuration reproducing the stale version pin, then improve doctor’s output to distinguish the configured package version from the current CLI version. I’d also clarify that the CLI’s catalogue does not establish which server version the client is currently running. I’d keep this read-only: no automatic updates, configuration writes, or changes to the pinning policy, with regression tests for stale, matching, and unknown-version registrations. @morluto, would you prefer this information in the existing diagnostic detail/remediation fields, or as structured fields as well? Is anyone already working on this? Otherwise, I’d be happy to take the focused fix. I haven’t reproduced it locally yet.

bsakaguchi commented

2026-10-15 18:30:42 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Addressed on main in ec56c1da0.

Doctor detects registration command and parsed package_reference drift without executing package managers or claiming remote contents.

Validation: Registration status tests 18 passed; global check, docs:check, Python and package verification pass.

Verification scope: Does not verify remote package contents.

@morluto commented on GitHub (Oct 14, 2026): Addressed on main in [ec56c1da0](https://github.com/morluto/rea/commit/ec56c1da0). Doctor detects registration command and parsed package_reference drift without executing package managers or claiming remote contents. Validation: Registration status tests 18 passed; global check, docs:check, Python and package verification pass. Verification scope: Does not verify remote package contents.

bsakaguchi referenced this issue

2026-10-16 21:02:23 +00:00

[GH-ISSUE #1065] [Feature] Roadmap: improve MCP usability and performance under bounded resources #390

bsakaguchi referenced this issue

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

[PR #1055] [MERGED] fix(javascript): complete large-ASAR analysis with file-local projection #2611

bsakaguchi referenced this issue

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

[PR #1088] [MERGED] fix(mcp): retain complete application results across response limits #2636

bsakaguchi referenced this issue

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

[PR #1101] [CLOSED] fix: cross-platform correctness, MCP transport ceiling, and Windows boundary stabilization #2649