Claude Code 2.1.274 quietly changed MCP: what to retest before a connector breaks
Claude Code 2.1.274 landed with a changelog that reads like housekeeping and behaves like a protocol change. Most of the interesting lines are about MCP, and most of them change what happens when a server is slow, old or slightly non-compliant. Those are exactly the servers people forget they run.
I'm working from the release notes as summarized by Releasebot, not from the source, and I haven't run 2.1.274 against my own servers yet. So this is a map of what to poke, with the caveat that I don't know the defaults behind several of these.
What changed under the hood
A new environment variable, CLAUDE_CODE_MCP_STARTUP_WAIT_MS, limits how long the client waits for MCP servers that are still connecting. I don't know the default, and the notes don't say what happens to tools from a server that misses the window (my guess is they show up late, but that is a guess). What matters is that startup is no longer implicitly unbounded for non-interactive runs.
Servers of type http that only speak the legacy HTTP+SSE transport used to fall over on 422 or other 4xx responses. There is now a fallback. That is a fix, but a fix to an error path changes behavior for anything that relied on the error.
Streamable HTTP calls that ran longer than about five minutes hit timeout trouble, and that is corrected. Prompts and resources now refresh even when the server never declared listChanged. Elsewhere in the release: an OpenTelemetry span carries the effort setting, corrupted transcripts self-heal, and sessions isolated in a worktree now refuse Bash commands that use certain nested expansions. The notes don't list which ones, so I can't tell you which of your scripts trip it.
Why quiet fixes are the risky ones
A crash is loud. A behavior that used to fail and now works, or used to work and now waits, is silent. If your server returned a 4xx during handshake and the client happened to recover another way, the new fallback may pick a different transport than before. If your server never sent listChanged notifications because you had no dynamic tools, the client now refreshes anyway, so your list endpoint gets called more often than you planned.
The dangerous MCP change is the one that turns an error you were quietly living with into a success you never designed for.
None of this is a complaint. I'd rather have the fallback. I just want to see it happen on my hardware before a CI job finds it for me.
A regression plan, in paragraphs
Start with the handshake. Point 2.1.274 and your previous version at the same legacy SSE-only server and record what each one does, including the raw status codes your server logs and which transport ends up in use. You are looking for a difference in the sequence of requests, not only the final outcome. Then do the same against a server that returns a deliberate 4xx on the first request, since that is the path the fix touched.
Next, time. Build a tool that sleeps for six minutes and returns, call it through Streamable HTTP, and confirm the result arrives. Do it once with a proxy or load balancer in front, because idle timeouts on the infrastructure between client and server are usually the real culprit and they don't care what the client fixed. Then set CLAUDE_CODE_MCP_STARTUP_WAIT_MS to something small, start a non-interactive run against a server you have delayed on purpose, and see what the session believes about its available tools. Write down the value that gives you a stable result.
Third, list refresh. Run a server that never declares listChanged, change its tool list between two turns, and check whether the client picks up the change and how many list calls your logs show. If you pay per request or rate limit, count them.
Finally the security and telemetry edges. Replay your real worktree-isolated automation once, unmodified, and grep for refused Bash calls. If your agent scripts build commands with nested substitutions, this is where they will surface. If you run self-hosted sessions, as in the restricted-mode setup I covered earlier, re-check your runners for authentication retry behavior, since the brief that flagged this release mentioned 401 handling specifically. And confirm the new effort span appears in your OTel backend without a cardinality surprise. If you need a refresher on how the client sees your servers at all, my note on Claude Code and MCP is the baseline.
I'd pin the version in CI until that plan has run once. It takes an afternoon, and it is cheaper than reading a failing pipeline at 2 a.m. while the connector that broke is one you wrote yourself, two years ago, for a demo, and never touched again. Those are the ones I'm worried about, honestly. Not the maintained servers, the forgotten ones.