[claude]

Requested by Felix Weinberger · Slack thread

Fixes #3022.

@modelcontextprotocol/node imports one function from @hono/node-server, getRequestListener. The range widens from ^1.19.9 to ^1.19.9 || ^2.1.3: a new install resolves 2.x, and an install that cannot get 2.x keeps 1.x, so no minimum moves. v1.x already accepts both majors.

The lockfile moves to 2.1.5. The node adapter tests pass on 1.19.11 and on 2.1.5; the integration and e2e suites pass on 2.1.5.

---

Generated by Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: ba512dd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@3084

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@3084

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@3084

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@3084

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@3084

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@3084

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@3084

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@3084

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@3084

commit: ba512dd

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline nits, I also checked two things about the move to the 2.x Hono node-server and ruled them out.

• Its node >=20 engines floor is not a new requirement for consumers: packages/middleware/node/package.json already declares node >=20, and its hono: ^4 || ^5.0.0-0 peer range is met by the locked hono 4.12.9.
• The 1.19.11 entry left in pnpm-lock.yaml is not stale: the transitive v1 MCP SDK (1.29.0) snapshot still depends on it, so both majors are expected in the lockfile.

Extended reasoning...

The change touches only the runtimeServerOnly catalog entry in pnpm-workspace.yaml, the regenerated pnpm-lock.yaml and a new patch changeset; no source, tests or package.json files change, and it touches no auth, injection or data-exposure surface. It is not approved because .github/CODEOWNERS assigns every path to the SDK team and because the default resolved major of a runtime dependency of a published package changes, which is a dependency decision for a maintainer.

[claude]

🟡 nit (optional): Consumers who stay on @ hono/node-server 1.x lose all CI coverage after this merge, although the range still promises 1.x works. The lockfile resolves the widened catalog range to 2.1.5 only (pnpm-lock.yaml:100), so every workspace test now runs on 2.x; the base ran them on 1.19.11. Fix: keep the 1.x half of ^1.19.9 || ^2.1.3 exercised, for example a CI job that runs the @ modelcontextprotocol/node tests with @ hono/node-server overridden to 1.19.x, or narrow the range to what is tested.

Why this was flagged

Trigger: a consumer upgrades @ modelcontextprotocol/node with an existing lockfile that already holds @ hono/node-server 1.19.x; the new range ^1.19.9 || ^2.1.3 (pnpm-workspace.yaml:43) is satisfied, so their package manager keeps 1.x. In this repo the catalog now resolves to 2.1.5 (pnpm-lock.yaml:99-100) and the packages/middleware/node importer and test/e2e both link 2.1.5 (pnpm-lock.yaml:1756, pnpm-lock.yaml:2020). The 1.19.11 entry that remains (pnpm-lock.yaml:3056) is referenced only by a third-party snapshot (pnpm-lock.yaml:7919), not by any workspace test. packages/middleware/node/src/streamableHttp.ts:91-101 and :200-208 call getRequestListener(..., { overrideGlobalObjects: false }), the one call that must behave the same on both majors. On the base branch CI ran these tests on 1.19.11; after merging nothing in .github runs them on 1.x, so a later change that only works on 2.x passes CI and breaks the 1.x installs the changeset says are kept. No safeguard applies: no workflow overrides the version.

Verification: Triggers when a consumer's install keeps @ hono/node-server 1.x, which the widened range still permits. pnpm-lock.yaml:99-100 resolves that catalog entry to a single version: version: 2.1.5. The base had version: 1.19.11. No job, override or script anywhere under .github installs 1.x.

_{Finding ID: f-ea558759}

[claude]

I reviewed the updated PR and found no new bugs; a maintainer look is still worthwhile because the follow-up commit amends the dependency policy and the change moves a runtime dependency on the HTTP request path to a new major.

What was reviewed:

• DEPENDENCY_POLICY.md "Pinning and Ranges" now agrees with the ^1.19.9 || ^2.1.3 catalog entry in pnpm-workspace.yaml.
• Engines: @ hono/node-server@ 2.1.5 needs node >=20, which matches the engines of @ modelcontextprotocol/node and the CI matrix (20, 22, 24), so no Node minimum moves.
• Lockfile: every catalog:runtimeServerOnly importer resolves to 2.1.5; the remaining 1.19.11 entry is still referenced by the @ modelcontextprotocol/sdk@ 1.29.0 snapshot, so it is not stale.
• Not checked here: runtime behaviour of getRequestListener(..., { overrideGlobalObjects: false }) on 2.x. Dependencies are not installed in this checkout, so the test results in the description were not reproduced.

Extended reasoning...

The change touches four files with no source edits: the runtimeServerOnly catalog range for @ hono/node-server, the regenerated lockfile, a patch changeset for @ modelcontextprotocol/node, and one sentence in DEPENDENCY_POLICY.md. It touches no auth, crypto or permission code, but the dependency converts Node HTTP requests and responses for NodeStreamableHTTPServerTransport, so every request on that transport goes through it. Deferring rather than approving because all changed paths fall under the repo-wide CODEOWNERS entry, the policy amendment is a maintainer decision, and behaviour on the new major could not be confirmed in this checkout.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.