morluto/rea

Fork 0

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

[GH-ISSUE #7027] [Bug] First client start after setup times out: pinned npx spec cold-install exceeds the MCP startup deadline #4256

New issue

Closed

opened 2026-10-31 00:48:09 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:48:09 +00:00

Owner

Originally created by @wxj006007 on GitHub (Oct 24, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7027

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 Windows, npx rea-agents@latest setup completed and registered the MCP server in three clients (ZCode, Claude Code, Codex) with the pinned command npx -y rea-agents@6.7.0 mcp. On the first client restart, the ZCode log recorded three consecutive connection failures — MCP server rea connection timed out after 30000ms — so the agent session started with no REA tools and reported REA as unavailable. The registration itself was intact; after the failed launches finished materializing the pinned package-runner cache entry, the next restart connected normally.

The root difference from the setup run: npm/npx keys its _npx cache by the request spec, so the rea-agents@latest entry that ran setup cannot serve the rea-agents@6.7.0 registration; the pinned entry is installed lazily inside the client's startup deadline on the first launch.

Reproduction

On Windows, run npx -y rea-agents@latest setup --client zcode --yes. This creates an _npx cache entry for the spec rea-agents@latest.
Restart the client (ZCode gives stdio MCP servers a 30000 ms startup budget). Observe three mcp.server.failed events: MCP server rea connection timed out after 30000ms.
After the killed launches complete the pinned entry's install, npx -y rea-agents@6.7.0 --version returns in ~2 s and the next client restart connects.

Frequency: 3/3 first-restart connection attempts failed; 1/1 later restart succeeded. Additional controlled measurement on the same machine: deleting the pinned _npx entry and re-running npx -y rea-agents@6.7.0 --version took 22 s with every package tarball already present in the shared _cacache store (no network download), versus 2 s warm and a ~1.1 s warm MCP initialize handshake. Under real restart load (several MCP servers starting concurrently, real-time antivirus scanning freshly extracted node_modules on Windows), the 22 s idle figure exceeded the 30 s budget in all three observed attempts.

Expected behavior

The first client start after a successful setup should stay within the client's startup deadline. docs/installation.md ("MCP Registry", persistent registrations pin one exact package version) makes the pinned registration intentional; setup should ensure the pinned spec's package-runner cache entry already exists before the user restarts — for example by materializing the pinned spec once at the end of setup (best-effort, non-fatal, bounded) — or the setup output should state that the first client start performs a one-time package install that can exceed short client startup deadlines.

Impact and scope

Affects every fresh setup and every version upgrade that pins a new exact version, for users whose registrations launch through the npm package runner; observed on Windows with ZCode. The failure is a one-time first-start timeout that users experience as a broken setup (the agent has no REA tools and reports REA unavailable), recoverable by restarting the client again. Not observed: first-start outcomes for Claude Code and Codex on this machine (their logs were not captured), and macOS/Linux behavior.

REA version

rea-agents 6.7.0 (npm package; setup run through npx rea-agents@latest)

Runtime and platform

Windows 11 x64 (10.0.26200), Node.js 24.14.0, npm with redirected cache root (_npx and _cacache under a custom directory); ZCode 3.16.3 stdio MCP startup budget 30000 ms. No analysis engine configured.

Target and artifact context

Not applicable — CLI/MCP server startup; no analysis target.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Client log (ZCode cli/log JSONL, timestamps UTC, redacted to the relevant fields):

2026-10-24T16:34:50Z mcp.server.connect.started  mcpServerName=rea
2026-10-24T16:35:20Z mcp.server.failed           error="MCP server rea connection timed out after 30000ms"
2026-10-24T16:35:26Z mcp.server.connect.started  mcpServerName=rea
2026-10-24T16:35:36Z mcp.server.failed           error="MCP server rea connection timed out after 30000ms"
2026-10-24T16:35:57Z mcp.server.failed           error="MCP server rea connection timed out after 30000ms"

Registration written by setup (ZCode user config, same shape for Claude Code and Codex):

{ "command": "cmd.exe", "args": ["/d", "/c", "npx", "-y", "rea-agents@6.7.0", "mcp"] }

Timing measurements on the same machine (supporting the cold-install cost claim):

warm  npx -y rea-agents@6.7.0 --version : 2 s
warm  MCP initialize handshake          : ~1.1 s
cold  reinstall (all tarballs in _cacache, no network): 22 s

For the cache-keying claim: separate _npx entry directories existed for rea-agents@latest (created by the setup run) and rea-agents@6.7.0 (created during the killed first launches; its node_modules contained rea-agents 6.7.0).

Typed outcome or recovery expected

After setup applies registrations, the pinned package-runner cache entry exists, so the first client start performs no dependency install and connects within the client deadline; or setup output explicitly notes the one-time first-start install and its deadline risk. A failed or offline pre-materialization must not fail setup.

Analysis or suspected cause

Source-derived: src/identity.ts builds registrationPackageSpecifier as rea-agents@<exact version>, and src/application/ClientRegistrationIdentity.ts composes the registered command from that specifier (npx -y <specifier> mcp, or the bunx variant). npm's npx cache is keyed by the request spec, so the entry installed for rea-agents@latest during setup is not reused for the pinned rea-agents@6.7.0 launch; the pinned entry is installed on first client start, inside the client's startup deadline. src/mcpStartupPolicy.ts documents a 30-second Codex startup_timeout_sec guidance value — a budget the same cold install can exceed. Suspected (not measured in isolation): concurrent MCP server startup and real-time antivirus scanning of the freshly extracted node_modules inflate the install time on Windows beyond the idle 22 s figure.

Additional context

Related first-start failure with a different root cause: #5259 (Windows 6.7.0 first start, ERR_MODULE_NOT_FOUND). I am preparing a PR that pre-materializes the pinned spec at the end of setup (best-effort, bounded, non-fatal) and can link it here.

Originally created by @wxj006007 on GitHub (Oct 24, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7027 ### 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 Windows, `npx rea-agents@latest setup` completed and registered the MCP server in three clients (ZCode, Claude Code, Codex) with the pinned command `npx -y rea-agents@6.7.0 mcp`. On the first client restart, the ZCode log recorded three consecutive connection failures — `MCP server rea connection timed out after 30000ms` — so the agent session started with no REA tools and reported REA as unavailable. The registration itself was intact; after the failed launches finished materializing the pinned package-runner cache entry, the next restart connected normally. The root difference from the setup run: npm/npx keys its `_npx` cache by the request spec, so the `rea-agents@latest` entry that ran setup cannot serve the `rea-agents@6.7.0` registration; the pinned entry is installed lazily inside the client's startup deadline on the first launch. ### Reproduction 1. On Windows, run `npx -y rea-agents@latest setup --client zcode --yes`. This creates an `_npx` cache entry for the spec `rea-agents@latest`. 2. Restart the client (ZCode gives stdio MCP servers a 30000 ms startup budget). Observe three `mcp.server.failed` events: `MCP server rea connection timed out after 30000ms`. 3. After the killed launches complete the pinned entry's install, `npx -y rea-agents@6.7.0 --version` returns in ~2 s and the next client restart connects. Frequency: 3/3 first-restart connection attempts failed; 1/1 later restart succeeded. Additional controlled measurement on the same machine: deleting the pinned `_npx` entry and re-running `npx -y rea-agents@6.7.0 --version` took **22 s with every package tarball already present in the shared `_cacache` store** (no network download), versus 2 s warm and a ~1.1 s warm MCP `initialize` handshake. Under real restart load (several MCP servers starting concurrently, real-time antivirus scanning freshly extracted `node_modules` on Windows), the 22 s idle figure exceeded the 30 s budget in all three observed attempts. ### Expected behavior The first client start after a successful setup should stay within the client's startup deadline. `docs/installation.md` ("MCP Registry", persistent registrations pin one exact package version) makes the pinned registration intentional; setup should ensure the pinned spec's package-runner cache entry already exists before the user restarts — for example by materializing the pinned spec once at the end of setup (best-effort, non-fatal, bounded) — or the setup output should state that the first client start performs a one-time package install that can exceed short client startup deadlines. ### Impact and scope Affects every fresh setup and every version upgrade that pins a new exact version, for users whose registrations launch through the npm package runner; observed on Windows with ZCode. The failure is a one-time first-start timeout that users experience as a broken setup (the agent has no REA tools and reports REA unavailable), recoverable by restarting the client again. Not observed: first-start outcomes for Claude Code and Codex on this machine (their logs were not captured), and macOS/Linux behavior. ### REA version rea-agents 6.7.0 (npm package; setup run through `npx rea-agents@latest`) ### Runtime and platform Windows 11 x64 (10.0.26200), Node.js 24.14.0, npm with redirected cache root (`_npx` and `_cacache` under a custom directory); ZCode 3.16.3 stdio MCP startup budget 30000 ms. No analysis engine configured. ### Target and artifact context Not applicable — CLI/MCP server startup; no analysis target. ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Client log (ZCode `cli/log` JSONL, timestamps UTC, redacted to the relevant fields): ```text 2026-10-24T16:34:50Z mcp.server.connect.started mcpServerName=rea 2026-10-24T16:35:20Z mcp.server.failed error="MCP server rea connection timed out after 30000ms" 2026-10-24T16:35:26Z mcp.server.connect.started mcpServerName=rea 2026-10-24T16:35:36Z mcp.server.failed error="MCP server rea connection timed out after 30000ms" 2026-10-24T16:35:57Z mcp.server.failed error="MCP server rea connection timed out after 30000ms" ``` Registration written by setup (ZCode user config, same shape for Claude Code and Codex): ```json { "command": "cmd.exe", "args": ["/d", "/c", "npx", "-y", "rea-agents@6.7.0", "mcp"] } ``` Timing measurements on the same machine (supporting the cold-install cost claim): ```text warm npx -y rea-agents@6.7.0 --version : 2 s warm MCP initialize handshake : ~1.1 s cold reinstall (all tarballs in _cacache, no network): 22 s ``` For the cache-keying claim: separate `_npx` entry directories existed for `rea-agents@latest` (created by the setup run) and `rea-agents@6.7.0` (created during the killed first launches; its `node_modules` contained rea-agents 6.7.0). ### Typed outcome or recovery expected After setup applies registrations, the pinned package-runner cache entry exists, so the first client start performs no dependency install and connects within the client deadline; or setup output explicitly notes the one-time first-start install and its deadline risk. A failed or offline pre-materialization must not fail setup. ### Analysis or suspected cause Source-derived: `src/identity.ts` builds `registrationPackageSpecifier` as `rea-agents@<exact version>`, and `src/application/ClientRegistrationIdentity.ts` composes the registered command from that specifier (`npx -y <specifier> mcp`, or the bunx variant). npm's `npx` cache is keyed by the request spec, so the entry installed for `rea-agents@latest` during setup is not reused for the pinned `rea-agents@6.7.0` launch; the pinned entry is installed on first client start, inside the client's startup deadline. `src/mcpStartupPolicy.ts` documents a 30-second Codex `startup_timeout_sec` guidance value — a budget the same cold install can exceed. Suspected (not measured in isolation): concurrent MCP server startup and real-time antivirus scanning of the freshly extracted `node_modules` inflate the install time on Windows beyond the idle 22 s figure. ### Additional context Related first-start failure with a different root cause: #5259 (Windows 6.7.0 first start, `ERR_MODULE_NOT_FOUND`). I am preparing a PR that pre-materializes the pinned spec at the end of setup (best-effort, bounded, non-fatal) and can link it here.

bsakaguchi

2026-10-31 00:48:09 +00:00

closed this issue
added the
bug

triage
labels

bsakaguchi referenced this issue

2026-10-31 01:12:16 +00:00

[PR #4274] [MERGED] fix(lifecycle): preserve observations and cleanup ownership #6153

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

No description provided.

Rows
Columns