next-devtools-mcp

Replaces the manual tag-and-publish flow with the Changesets "Version Packages" PR workflow, matching . On push to , opens or updates a Version Packages PR while changesets accumulate, then publishes to npm when that PR merges. Contributors add a changeset with . Publishing uses npm trusted publishing (OIDC) — no , provenance automatic — so the job runs Node 22 and (OIDC needs npm >= 11.5.1). makes the bot's commits and tags GPG-signed, which this repo's require-signed-commits ruleset ( branches) demands. Removes , now superseded.

Claude Code v2.1.71 No configured next-devtools-mcp 0.3.10 next 16.1.6 macOS Sequoia 15.7.4 Apple M1 Pro Everything works correctly. Claude reports () next-devtools · :heavy_check_mark: connected After prompting to make sure, Claude reports The ... dev server is running on port 4200, and the next-devtools MCP connected successfully. However when exiting Claude (e.g. with ), it consistently reports 1 MCP server failed With this being the only MCP server configured. Asking Claude to diagnose, it reports This is a cosmetic issue, not a real problem. When Claude Code exits, it sends a shutdown signal to any MCP server subprocesses it manages. The next-devtools MCP server (running on port 4200) likely exits with a non-zero code when it receives that signal — which Claude Code reports as "failed." The actual Next.js dev server process continues running fine; only the MCP sidecar connection is torn down. Why it happens: MCP servers started by Claude Code are treated as managed subprocesses. On exit, Claude sends SIGTERM and waits briefly. If the process exits with a non-zero status (common for servers that don't handle SIGTERM gracefully), it's counted as a failure. Is it a problem? No. The ... dev server on port 4200 is unaffected. The message is just Claude Code reporting that the MCP subprocess didn't exit cleanly. To suppress it: You'd need the next-devtools package to handle SIGTERM and exit with code 0 — that's an upstream fix in the mcp__next-devtools package, not something you can easily configure from Claude Code's side. This is not critical, but seeing that red "failed" error every time activates my inner "something is wrong" system.

Problem When the MCP host (e.g. Claude Code) sends to terminate the server on exit, users see: 1 MCP server failed even though everything worked correctly and the exit code is . The host interprets the abrupt stdio disconnect as a failure. Fix in called without first telling the MCP to close, so the stdio transport was torn down abruptly instead of cleanly. This makes async and before exiting, so the SDK can close the transport cleanly: Note:** this PR originally also removed duplicate / handlers that called from . That file was removed by #145 in the meantime, so after rebasing onto only the change remains. Fixes #126, relates to #113