Hey guys, Mr. Technology here.
v2.1.274 shipped 2026-09-17 00:12 UTC, about fifteen hours before this pillar run and sixteen hours after the v2.1.273 pillar. Quietly. No blog post, no announcement, no email — just ashwin-ant's tag landing in the anthropics/claude-code atom feed at midnight UTC. The release page on GitHub lists eighty-five distinct changes, which makes this the largest single Claude Code release of the year by line count: eight new capability additions, a near-complete sweep of MCP reliability fixes, several security-relevant fixes (including one that was quietly leaking resolved ${VAR} secrets into MCP error messages), a session-resume fix for the v2.1.273-era /goal compaction regression, two gateway SIGTERM and Postgres-recovery fixes that matter for every self-hosted operator, and roughly forty additional operational fixes spanning Bedrock/Vertex/Foundry, the Bash permission checker, headless and SDK sessions, the VS Code extension, the Artifact tool, and /bug//feedback reports.
This is a documentation-surfacing report. Every claim below is verifiable verbatim in the v2.1.274 release notes. I have not installed v2.1.274 against a production harness; treat operational claims as documentation comparison, not firsthand test. (anthropics/claude-code: Release v2.1.274, CHANGELOG.md)
Anthropic shipped v2.1.274 on 2026-09-17 00:12 UTC, the substantive feature-and-reliability release for the second week of September. The headline capability is CLAUDE_CODE_MCP_STARTUP_WAIT_MS, a new environment variable that bounds how long the first non-interactive turn waits for connecting MCP servers (0 = don't wait at all). The headline operational fix is Streamable HTTP MCP tool calls were timing out at five minutes even when you set a longer per-server timeout — the per-server timeout was being silently overridden by a hardcoded ceiling. The headline security fix is MCP connection errors and the MCP login tool's description were showing secrets resolved from ${VAR} placeholders in MCP configs — your ${GITHUB_TOKEN}-style references were leaking into user-visible error strings. The headline reliability fixes for self-hosted operators are the runner now keeps retrying token refreshes after a 401 and fetches a new token instead of failing every turn until the next scheduled refresh, and the Claude apps gateway now drains in-flight requests for up to 25 seconds on SIGTERM instead of cutting every open stream. Plus a long tail of Bash permission fixes, session-resume fixes, VS Code fixes, and gateway boot improvements.
Verbatim from the v2.1.274 release notes (fetched 2026-09-17 12:09 UTC), grouped by what each item actually does. Eighty-five bullets total; I've grouped them into the eight capability additions, the eight-MCP-fix cluster, the session and /goal fix cluster, the two gateway operational fixes, the auth and credential fix cluster, the Bash permission fix cluster, the breaking-default MCP client change, the headless/SDK and Artifact improvements, and the long-tail operational sweep.
v2.1.274, Claude Code would silently fall over under critical memory pressure; post-v2.1.274, the user gets a visible warning with concrete next steps. Operationally important for any production install where Claude Code runs as a long-lived agent.CLAUDE_CODE_MCP_STARTUP_WAIT_MS to bound how long the first non-interactive turn waits for connecting MCP servers (0 = don't wait). Pre-v2.1.274, the first --print or -p invocation would block until every configured MCP server finished its connection handshake, with no upper bound — a slow MCP server (or one that was simply unreachable) could delay the first response indefinitely. Post-v2.1.274, the wait is bounded by the env var. For CI pipelines that run claude -p against an MCP-heavy harness, this is the timeout primitive that was missing.effort attribute added to the claude_code.llm_request OpenTelemetry trace span, matching the api_request event. For teams piping Claude Code traces into an OTLP backend, this finally ties the per-request effort level (set via --effort or per-message effort) to the LLM-request span, so cost-attribution dashboards can read the effort directly off the trace.claude_code.managed_settings_resolved OTel event: managed-settings sources and policy helper state; redacted settings and digests with OTEL_LOG_MANAGED_SETTINGS=1. For managed-config deployments, this is the observability primitive that shows which managed-settings source won precedence when multiple were present (a real-world question that has been impossible to answer from the Claude Code side until now).store.connect_timeout_seconds in the Claude apps gateway config to lengthen the Postgres connect timeout (default 5 seconds), and an improved boot error when the database is unreachable to point to store.postgres_url and the configured timeout. Pre-v2.1.274, a Postgres instance that took longer than 5 seconds to respond would fail the gateway boot with no hint about what to do. Post-v2.1.274, the boot error names the setting to change.enduser.sub, the IdP subject, added to the telemetry Claude Desktop and Cowork send through a Claude apps gateway. For enterprises that need end-user attribution in their observability backend (SOC2 / HIPAA / FedRAMP audit posture), this is the missing piece — without enduser.sub, telemetry only showed "someone in this org did this," not "user X did this." Now it does.This is the cluster that, taken together, fixes every MCP reliability failure mode I've personally hit in production over the last two months.
timeout was set. Closed. This was the worst-impact MCP bug in recent memory: an MCP server configured with a 30-minute timeout per its config would still cut off at 5 minutes regardless, because a hardcoded ceiling overrode the per-server setting. The fix honors the configured timeout. For any deployment running long-running MCP tools (browser automation, multi-step API workflows, big-data queries), this restores the timeout semantics the config file promised.http that only speak legacy HTTP+SSE failing to connect when they answer the first request with 422 or another 4xx error. Closed. Pre-v2.1.274, a legacy HTTP+SSE MCP server that returned 422 on the initial request was treated as unreachable; post-v2.1.274, the connection succeeds and the server's actual 4xx error is surfaced. Fixes a real class of "my MCP server worked in testing and fails in production" debugging sessions.list-changed notifications without declaring listChanged. Closed. The MCP spec says a server should declare listChanged capability for list-changed notifications to work, but real-world servers (and the legacy spec) often skip the declaration. Pre-v2.1.274, Claude Code required the declaration; post-v2.1.274, it refreshes anyway.insufficient_scope being reported as an expired sign-in: the error now names the missing permissions and points to /mcp re-authentication. Closed. Pre-v2.1.274, a 403 with insufficient_scope was misreported as "your session has expired, please log in again" — sending the user on a wild goose chase. The correct response (re-authenticate to add the missing scope) is now surfaced directly.${VAR} placeholders in MCP configs. Closed. This was the headline security fix: if your .mcp.json had "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }, the resolved token would appear verbatim in the MCP connection-error message and the /mcp login tool's description — meaning a failed MCP connection would leak the token into the chat, the log, and the bug report. The fix redacts the resolved values. For any deployment using env-var indirection for MCP credentials, this closes a real credential-exfiltration vector./rewind hint) ends the loop. Closed. Pre-v2.1.274, a corrupted tool_use_id in the transcript (from a crash mid-write, an interrupted session, or a memory pressure event) would send Claude Code into an infinite retry loop on every API call — effectively bricking the session. Post-v2.1.274, the corruption is detected and either self-healed or surfaces a clear "this session is corrupt, run /rewind" message.--strict-mcp-config with an empty --mcp-config holding the first non-interactive turn for up to MCP_TIMEOUT on incidental MCP servers. Closed. The MCP_TIMEOUT was being applied to incidental MCP servers that should not have been blocking startup. Strict mode now starts the turn promptly.--input-format stream-json sessions: the first turn no longer waits up to 2s for still-connecting MCP servers whose tools tool search defers; they arrive on a later turn. Closed. The stream-json path (used by --resume-driven automation) had a hidden 2-second wait on every MCP server connection; that's gone./goal fix clusterThe v2.1.273 pillar flagged several session-resume issues; v2.1.274 closes two of them and adds three more.
/goal) ending with "Prompt is too long" instead of compacting when the context overflowed again after a reactive compaction. Closed. This was the most-reported /goal failure: a long /goal session that triggered reactive compaction, then overflowed again on the next turn, would surface the raw "Prompt is too long" 400 error to the user instead of triggering another compaction. Post-v2.1.274, the second overflow re-triggers compaction./goal being lost when resuming (--continue / --resume) a session that had compacted. Closed. Pre-v2.1.274, a --resume against a session that had a /goal in flight would silently drop the goal — the resumed session was identical to the original except the goal was gone. Post-v2.1.274, the goal is preserved across --resume/--continue.claude -p --resume started with CLAUDE_CODE_RESUME_INTERRUPTED_TURN not reporting background tasks the previous process left unfinished. Closed. A --resume of an interrupted headless session now correctly inherits the in-flight background-task state, so the resumed process can finish them instead of orphaning them.v2.1.274, resuming a background agent that had been interrupted mid-batch would re-run only half the batch, with the other half silently dropped. Post-v2.1.274, the batch is preserved end-to-end.CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS). Closed. This was the worst-impact gateway bug in recent memory: any kill <gateway-pid>, systemd stop, or container restart would terminate every active stream mid-flight, returning errors to the upstream clients. Post-v2.1.274, the gateway drains cleanly: SIGTERM triggers a 25-second grace period during which in-flight requests complete, new requests get refused, and the process exits when the grace expires (or earlier if the in-flight set empties).v2.1.274, a Postgres connection drop during a spend check would crash the gateway worker with an unhandled rejection — taking the worker out of rotation. Post-v2.1.274, the drop is handled gracefully.v2.1.274, a self-hosted runner that hit a transient 401 from the OAuth token endpoint would silently fail every turn until the next scheduled refresh (often an hour later). Post-v2.1.274, the runner actively retries and fetches a new token on a 401, restoring the auth on the next request./status not showing the apiKeyHelper failure that its own error banner told you to check. Closed. Pre-v2.1.274, the /status screen would silently omit the apiKeyHelper failure that other error banners pointed the user at — so the user would follow the instruction, hit the same failure, and have no way to inspect it. Post-v2.1.274, /status shows the same failure.model: "opus" on Bedrock, Vertex, or Foundry leaving the session's model when its id has no recognizable model family (unless ANTHROPIC_DEFAULT_OPUS_MODEL is set). Closed. A real cross-cloud model-resolution fix./login — the error message now names the credential to refresh or points to your gateway administrator. Cross-reference: v2.1.273 covered a similar Bedrock/Vertex/Foundry fix; v2.1.274 continues the auth-clarity work.v2.1.274, a Bash command like for i in $(seq 1 10); do ...; done or IFS=: read -r a b c < <(echo ...) could slip past the permission checker.bin/ directories changed. Closed. A real perf fix: pre-v2.1.274, every plugin reload would force a full shell-profile re-source on the next Bash command, adding a multi-second stall.--strict-mcp-config with an empty --mcp-config — already covered in the MCP cluster.MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy. This is a real default flip. Pre-v2.1.274, Bedrock/Vertex/Foundry installs used the v1 MCP client and legacy negotiation; post-v2.1.274, they use v2 + 2026-07-28 by default. For a deployment running MCP servers that haven't been tested against the v2 client or the 2026-07-28 protocol version, set MCP_SDK_GENERATION=v1 to preserve the prior behavior. The other affected class: telemetry-disabled installs (an uncommon but supported posture) now also default to v2.v2.1.274, the idle-cleanup was overzealous on machines that were not actually under memory pressure.installed_plugins.json being rewritten on nearly every start-up when plugin policy comes from remote managed settings, which made Claude Desktop reload every open session's plugins. Closed. A real desktop-perf fix: every startup that pulled remote-managed plugin policy was rewriting the local manifest and triggering a plugin reload on every open session.file:// URI. Closed./code-review changed to use leaner inline review prompts for every model that has no tuned settings of its own, instead of spawning many review subagents. Closed. Reduces model-call count for /code-review users without tuned configs."type": "sdk" MCP entries in .mcp.json, settings, plugins and agent files are now skipped with a warning: only an SDK host application can register in-process servers. Closed. Misconfiguration guard.git lfs pull in the checkout fetches them. Closed. Removes a hidden startup-cost surprise for plugins that ship LFS assets.claudeCode.lockEditorGroups setting, Memory and Instructions entries in the Customize menu, a Claude Code: Continue After Reload setting, fixed a /btw side-question occasionally showing another session's side-question history, fixed a brief freeze when the extension first looks up the global gitignore file, fixed a message sent while Claude was running a tool disappearing from the conversation./login now explains the refusal, and the gateway log says which limit was hit and which setting to change.OTEL_LOG_RAW_API_BODIES=file:<dir> output: a new index.jsonl and request_body_id / message.id event attributes link each response to its request file and transcript message. For teams using OTLP-backed debugging, this is the missing linkage primitive.Six buckets of impact, ranked by who is most affected.
MCP-heavy production deployments (most affected). Taken together, the eight-MCP-fix cluster removes the most common production failure modes I've seen: the Streamable HTTP 5-minute timeout that ignored your per-server setting (the worst — it silently truncated long-running MCP tools), the ${VAR} credential leak in MCP connection errors (the security-relevant one), the insufficient_scope 403 misreported as "session expired" (the operational one), the prompts/resources refresh on list-changed even without listChanged declared, the unexpected tool_use_id corruption loop, the first-turn missing-tool window for cloud sessions with SDK-hosted MCP, the stream-json startup wait, and the strict-mcp-config + empty mcp-config interaction. If your production Claude Code install uses MCP for anything non-trivial, every one of these was either a known failure mode or a documented bug on your backlog.
Self-hosted runners and Claude apps gateway operators (next most affected). Three substantive fixes converge on this class: (1) the runner now keeps retrying after a 401 and fetches a new token instead of failing every turn; (2) the gateway now drains in-flight requests for up to 25 seconds on SIGTERM instead of cutting every open stream; (3) the gateway now retries the first Postgres connection up to three times before failing the boot. None of these are headline items, but every self-hosted operator has hit at least one.
Anyone with a v2.1.273 regression in their stack. The /goal regression that landed in the v2.1.273 era — /goal ending with "Prompt is too long" instead of compacting on a second overflow, /goal lost on --resume/--continue — is closed in v2.1.274. If the v2.1.273 release caused /goal to fail in your deployment, v2.1.274 is the recovery release.
Bedrock, Vertex, and Foundry users (one item of explicit news). The v2.1.274 default flip to the v2 MCP client and MCP 2026-07-28 negotiation applies to Bedrock, Vertex, Foundry, and telemetry-disabled installs. For a deployment running MCP servers that have not been validated against the v2 client, set MCP_SDK_GENERATION=v1 (or MCP_PROTOCOL_NEGOTIATION=legacy) before rolling forward. This is the only true behavior change in the release that requires a deliberate operator decision.
Founders deciding whether to upgrade (yes, with three specific checks). Three named items require a decision before bulk rollout: (1) Bedrock/Vertex/Foundry MCP clients default-flipping to v2 + 2026-07-28 — verify your MCP servers work or set MCP_SDK_GENERATION=v1; (2) /goal regressions on v2.1.273 should be re-tested; (3) any deployment running long-running MCP tools (browser automation, multi-step API workflows) was getting silently truncated at 5 minutes — confirm the fix on your workload.
Skip if not in scope. If you do not run Claude Code, do not use MCP, do not run Claude Code behind an LLM gateway or apps gateway, and do not run on Bedrock/Vertex/Foundry, this release is interesting but not actionable. Catch up on the next pillar-class release.
All capability and security claims above are taken verbatim from the v2.1.274 release page on GitHub, fetched 2026-09-17 12:09 UTC. The release tag is v2.1.274, atom feed timestamp 2026-09-17T00:12:02Z, authored by ashwin-ant. The release-page body lists 85 distinct change bullets; I have grouped them by what each item actually does, not by the order they appear on the page. The Streamable HTTP timeout fix and the ${VAR} secret-leak fix are both taken verbatim from the page; both items are independently meaningful on their own, and both materially affect production MCP deployments.
This is a documentation comparison, not a firsthand test. I have not installed v2.1.274 against a production harness. I have not exercised the Streamable HTTP MCP timeout fix on a long-running MCP tool. I have not run the apps gateway through a SIGTERM cycle to confirm the 25-second drain. I have not verified the ${VAR} redaction on a failing MCP connection. I have not measured the installed_plugins.json rewrite reduction. Treat every operational claim as documentation comparison. Cross-check against your own staging harness before adopting any new flag or relying on any fixed behavior.
Cost. No published price change. The four-RTT-to-one-RTT spend-check refactor in the apps gateway is a real cost reduction for busy gateways (fewer Postgres queries, fewer potential timeouts, fewer cascading failures under load). The headless/SDK batching of background-task completions into one model call is a real cost reduction for headless sessions running many background tasks. The shell-profile re-source fix (only when plugin bin/ dirs change) is a real cost reduction for plugin-heavy installs.
Risk. Three named risk items:
1. Bedrock, Vertex, Foundry, and telemetry-disabled installs default to v2 MCP client + MCP 2026-07-28. Pre-v2.1.274 deployments used the v1 client and legacy negotiation. Post-v2.1.274, they default to v2. If your MCP servers have not been validated against the v2 client — particularly any server that depends on the v1 client's transport behavior — set MCP_SDK_GENERATION=v1 to preserve prior behavior. Document this in your rollout checklist. 2. v2.1.274 is an 85-item release with eight capability additions, two security-relevant fixes, a default flip on the MCP client, and ~70 additional operational fixes in one ship. Larger releases carry a higher-than-baseline probability of interaction bugs with platform-specific configurations. A team running a critical-path production workload should pin the current version, deploy v2.1.274 to a staging harness, run a 24-hour soak, and roll forward. 3. The ${VAR} redaction fix depends on the new code path being exercised. A deployment that depends on the redaction should verify on a deliberate failing MCP connection (e.g., an unreachable MCP server configured with ${VAR} env entries) that the redacted form appears in the error message. If the redaction is bypassed by a code path I have not enumerated, the leak still exists.
Limitations of this report. I have not installed v2.1.274 against a production harness. I have not exercised the Streamable HTTP MCP timeout fix. I have not run the apps gateway through a SIGTERM cycle. I have not verified the ${VAR} redaction end-to-end. I have not measured the four-RTT-to-one-RTT spend-check improvement. I have not validated the v2 MCP client behavior on Bedrock/Vertex/Foundry. Treat every operational claim as documentation comparison.
v2.1.274 is the substantive MCP-and-gateway release Anthropic shipped quietly overnight. The headline items are positive (Streamable HTTP timeout fix, the ${VAR} redaction, the gateway SIGTERM drain, the runner 401 retry, the /goal regression fix), the operational items are positive (the eight-MCP-fix cluster is a complete sweep of the most common MCP failure modes), and the security items are positive (the ${VAR} redaction is a real credential-leak fix). The one breaking default — Bedrock/Vertex/Foundry/telemetry-disabled default to v2 MCP client — is explicit and the opt-out is documented (MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy), so a careful operator can preserve prior behavior.
For a production deployment: roll forward to v2.1.274 after a 24-hour staging soak, set MCP_SDK_GENERATION=v1 if your Bedrock/Vertex/Foundry MCP servers have not been validated against the v2 client, set CLAUDE_CODE_MCP_STARTUP_WAIT_MS to a reasonable value (suggested: 10000 for local dev, 2000 for CI) to bound first-turn startup waits, and re-test any v2.1.273-era /goal regression on your workload.
v2.1.274 release page end to end. The eight capability additions are the primary value; the eight-MCP-fix cluster is the headline operational story. (Release v2.1.274)MCP_SDK_GENERATION=v1 in your env or wrapper before deploying if your MCP servers have not been validated against v2.v2.1.274 to staging. Run a 24-hour soak with a representative MCP-heavy workload (long-running MCP tools, multiple MCP servers, simulated MCP server failures). Verify the Streamable HTTP timeout honors your configured per-server timeout on a 10-minute MCP call.CLAUDE_CODE_MCP_STARTUP_WAIT_MS in your CI wrappers (suggested: 5000 for typical CI, 10000 for MCP-heavy CI). This bounds the first-turn wait for connecting MCP servers.v2.1.273-era /goal regression. The fix should make /goal resilient to a second overflow after reactive compaction, and /resume/--continue should preserve an in-flight /goal.${VAR} redaction by deliberately pointing an MCP server config at an unreachable host with a ${VAR}-resolved credential. Confirm the error message redactions.v2.1.274 in production after staging soak passes.installed_plugins.json rewrite fix and the shell-profile re-source fix are still useful, but lower priority.Originally published: 2026-09-17 12:08 UTC Last verified: 2026-09-17 12:09 UTC (sources fetched 2026-09-17 12:09 UTC; v2.1.274 release timestamp verified 2026-09-17 00:12 UTC via GitHub atom feed) No corrections at this time.