Claude Code 2.1.274 warns before memory turns critical

Type "3. 2. 1." into Claude Code and the transcript used to renumber your list as "3. 4. 5.". That is fixed in v2.1.274, published by Anthropic on Github as a list of more than a hundred entries whose headline item is a visible warning when memory usage goes critical, with steps to free memory or restart safely.

At a glance

• Claude Code 2.1.274 lists more than a hundred changes across the CLI, the VS Code extension, cloud sessions, Claude Tag and Code Review, from memory pressure to Postgres connect timeouts in the apps gateway.
• CLAUDE_CODE_MCP_STARTUP_WAIT_MS caps how long the first non-interactive turn waits for connecting MCP servers, with 0 meaning no wait, and store.connect_timeout_seconds lengthens the gateway's five-second Postgres connect timeout.
• Two limits the changelog leaves open: what counts as critical memory usage, and what the startup wait is when you leave CLAUDE_CODE_MCP_STARTUP_WAIT_MS unset.

If you have not been following the point releases, they arrive at a steady clip. The version immediately before this one, v2.1.272, landed on September 14 and, according to the Claude Code Ultimate Guide archive, was described only as bug fixes plus per-command allowed_domains for Bash, PowerShell and Monitor in auto mode. The same archive notes a recent breaking change that gave Monitor watches a hard deadline of 30 minutes.

Background commands now stop only when memory is critically low

The warning is the visible half. When memory usage goes critical, Claude Code says so on screen and lists what you can do about it: free memory, or restart safely.

Underneath sits a fix. Background commands used to be stopped after 30 idle minutes on machines under mild memory pressure; they are now stopped only when memory is critically low, and the debug log says why.

Other local stalls went with it. A per-turn slowdown is gone when a language server publishes project-wide diagnostics for thousands of files, and the Bash tool no longer re-sources the shell profile after every plugin reload, which cost a multi-second pause on the next command; it now does so only when the plugins' bin/ directories changed.

Why did the first turn wait for MCP servers?

Because a tool that has not connected yet is a tool Claude cannot call. At session start Claude Code connects to each configured MCP server, and a non-interactive run has nobody sitting there to decide, so it held the first turn until the servers answered.

CLAUDE_CODE_MCP_STARTUP_WAIT_MS puts a ceiling on that wait, and 0 means do not wait at all. It works like the few minutes you hold a meeting for a late colleague: whoever makes it is in the first turn, the rest join later.

Two related fixes. The combination of --strict-mcp-config and an empty --mcp-config no longer holds the first non-interactive turn for up to MCP_TIMEOUT on incidental servers, and stream-json sessions no longer wait up to 2s for connecting servers whose tools tool search defers; those tools arrive on a later turn.

Streamable HTTP tool calls stopped at about five minutes whatever the timeout said

Streamable HTTP MCP tool calls used to time out after roughly five minutes even when a longer per-server timeout was configured. Also fixed: servers configured as http that only speak legacy HTTP+SSE failed to connect when they answered the first request with 422 or another 4xx.

Prompts and resources now refresh when a server sends list-changed notifications without declaring listChanged. A tool call refused with 403 insufficient_scope names the missing permissions and points at /mcp re-authentication, instead of being reported as an expired sign-in. And MCP connection errors and the login tool's description no longer show secrets resolved from ${VAR} placeholders in MCP configs.

Bedrock, Vertex, Foundry and telemetry-disabled installs now use the v2 MCP client and MCP 2026-07-28 negotiation with direct HTTP servers by default, as other installs already did. MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy opt out.

The apps gateway now lets in-flight requests finish for 25 seconds

The Claude apps gateway is the piece that Claude Desktop and Cowork talk through, with Postgres behind it. On SIGTERM it used to cut every open stream; it now gives in-flight requests up to 25 seconds to finish before exiting, tunable with CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS.

Boot changed twice over. store.connect_timeout_seconds lengthens the Postgres connect timeout past its five-second default, and the first connection is retried up to three times before the process gives up, so a database that comes back a few seconds late no longer fails the boot. The unreachable-database error now points at store.postgres_url and the configured timeout.

Under load, the spend-limit check takes one database round trip instead of four. A replica holding more open requests than the 256 it sends upstream at once logs a warning, and that limit is printed at startup. Telemetry sent through a gateway now carries enduser.sub, the IdP subject.

Some of this reads as catching up with the way people actually run Claude Code on busy machines and busy servers. In our view the most telling line sits far down the list: until this release the apps gateway cut every open stream the moment it got SIGTERM, so an ordinary restart was something the person mid-request noticed.

When legacy MCP negotiation ends

Both opt-outs ship in this release, MCP_SDK_GENERATION=v1 and MCP_PROTOCOL_NEGOTIATION=legacy, and no date is given for their removal, so Bedrock, Vertex and Foundry installs can stay on the v1 client for now. One thing is already refused outright: "type": "sdk" MCP entries in .mcp.json, settings, plugins and agent files are skipped with a warning, because only an SDK host application can register in-process servers. Whether the v1 path gets the same treatment is not stated.