MCP Client Changelog August 2026: Host Updates & What to Test

Eight MCP clients and host platforms published August updates that may affect how your server authenticates, survives slow connections, returns resource content, gets discovered, or passes enterprise policy.

This is the second edition of the series, following the MCP Client Changelog for July 2026. Here is what changed, who is affected, and what MCP server developers should test.

August 2026 MCP Changes at a Glance

Protocol Mechanics Changes

Cline: Live Capability Refresh, OAuth on a 401, and Startup Isolation

Cline 4.1.4 refreshes tool and resource lists when your server sends list_changed. The notification tells the client that the server's advertised capabilities have changed. Previously, Cline could notify the user without refreshing its cached lists, leaving a newly added tool invisible or a removed tool available until reconnect.

Cline 4.1.7 changed remote authentication and startup behavior:

• Remote servers can use pre-registered OAuth clients when dynamic registration is unavailable.

• An SSE server returning 401 Unauthorized can surface an OAuth authorization flow instead of failing the connection immediately.

• A hung server no longer blocks overall session creation. An unconfigured stdio server receives a 30-second initialization budget instead of waiting indefinitely.

One slow local server should now fail on its own rather than making every other configured server unavailable.

Goose: Embedded Resources, OAuth Transport, and Tool Visibility

Goose 1.46.0 began forwarding images and embedded-resource blobs into Anthropic and Google provider formats. An embedded resource is content returned as resource data rather than plain text. If a client drops that content while converting the result into a model-provider format, the model receives an incomplete result even though the server completed the call successfully.

Goose 1.47.0 added pre-registered OAuth clients for Streamable HTTP extensions and began enforcing secure OAuth token transport. Test remote deployments with the exact transport and authorization-server configuration that you support in production.

Goose 1.48.0 changed two surfaces that determine what the model sees:

• Goose sanitizes Unicode tag characters in MCP prompts. Test both malicious hidden content and legitimate Unicode text so sanitization does not corrupt valid prompts.

• Code Mode now honors MCP tool model-visibility rules. A tool hidden from a particular model context should no longer remain callable through Code Mode.

Claude Code: OAuth Fixes and Bounded Connection Failures

Claude Code's August MCP releases focused on authentication and connection reliability.

Version 2.1.231 fixed an OAuth redirect URI mismatch affecting servers that use pre-registered clients. The remaining releases addressed different ways a connection could stall:

• Version 2.1.232 fixed a connection that could remain stuck during the 30-second connect timeout when a server did not answer or returned a malformed protocol-version reply.

• Version 2.1.233 stopped MCP v2 connections from repeatedly reopening a subscriptions/listen stream after infrastructure terminated the long-lived connection on a fixed timeout.

• Version 2.1.251 bounded failure handling when an SDK MCP server's handshake acknowledgment was lost. Only the affected server should fail instead of holding the broader session open.

These fixes turn malformed replies, infrastructure timeouts, and lost acknowledgments into bounded failures. Your regression suite should verify both the failure time and the continued availability of healthy servers.

Codex: Issuer Binding, Credentials Across Executors, and Modified Results

Codex 0.150.0 fixed remote MCP bearer-token lookup and required-server startup while preserving compatibility with older executors. An executor is the environment in which Codex runs part of a task. One session can use several executors, and each must resolve the credentials needed to reach the same MCP server.

The release also enforced issuer binding for MCP OAuth endpoints. Codex checks the relationship between the authorization metadata, its advertised issuer, and the authorization and token endpoints before beginning the flow. This prevents untrusted metadata from redirecting OAuth material to an unrelated origin.

Codex 0.151.0 made the grace period for discovering tools from optional MCP servers configurable. It also allowed extensions to inspect or replace successful and error results before they reach the model, while the app-server path preserved structured MCP tool and resource errors.

When an extension participates in the tool lifecycle, the result emitted by your server may differ from the result presented to the model. Tests should observe both boundaries.

MCP Distribution and Governance Changes

August also changed how MCP servers are discovered, distributed, and permitted to run before ordinary tool traffic begins.

Claude: Enterprise-Managed Authorization

Anthropic made enterprise-managed authorization for MCP connectors generally available on August 24. An administrator provisions supported connectors through the organization's identity provider, and users inherit access through existing groups and roles without authorizing each server separately.

The MCP Enterprise-Managed Authorization extension makes the identity provider the policy authority. The client exchanges an IdP-issued assertion for an access token without redirecting the user to the server's authorization endpoint. Authorization moves rather than disappears: the authorization server must validate the assertion's signature, issuer, audience, expiration, and relevant claims before issuing a token.

AgentCore: Discovery Moves Into a Governed Registry

AWS moved AWS Agent Registry to general availability. The registry provides a private catalog of agents, tools, skills, MCP servers, and custom resources. Records can be discovered through AWS APIs or through the registry's MCP endpoint.

The August release also added automatic discovery of AgentCore Runtimes and Gateways across AWS Organizations member accounts, customer-managed KMS encryption for registry data, and private access through AWS PrivateLink.

AgentCore Gateway added configurable rate limits scoped to callers, targets, tools, or models. It can limit requests, inference tokens, and new connections. For a server behind the gateway, throttling is part of the configured production environment. Clients must back off without creating an uncontrolled retry loop.

GitHub Copilot and VS Code: Governed Servers and Packaged Configuration

GitHub made MCP allowlists in enterprise managed settings generally available. Enterprise owners can identify permitted or denied servers using three matchers:

• serverUrl matches remote HTTP and SSE servers. It supports wildcards and canonicalizes URLs.

• serverCommand matches local stdio servers by exact command and arguments.

• serverName matches a user-assigned label. GitHub describes this as a convenience, not a security control, because users can rename a server.

For example, this plugin configuration is valid:

{
  "mcpServers": {
    "acme-deploy": {
      "type": "http",
      "url": "https://mcp.acme.com/deploy"
    }
  }
}

An enterprise rule matching https://mcp.acme.com/tools will still block it. The packaged url and the policy's serverUrl must identify the same endpoint.

The policy fails closed. A malformed or unverifiable configuration is blocked, and a server must satisfy every applicable policy layer. The allowlist is currently enforced in the GitHub Copilot app, Copilot CLI, and VS Code.

GitHub also announced Agent Plugins 1.0, published with AWS, Anysphere, Microsoft, OpenAI, and Vercel, with Google joining as a core maintainer. A plugin can package skills and MCP server configuration into one installable unit. MCP configuration lives in mcp.json.

Compatibility therefore begins before the MCP handshake. Treat remote URLs, local commands and arguments, registry metadata, and packaged mcp.json configuration as deployable interfaces. Keep them stable, versioned, and consistent with enterprise policy.

How to Test an MCP Server Against August 2026 Client Changes

Add the following cases to your regression suite.

Use protocol traces for wire-level failures, an OAuth debugger for authorization failures, and cross-client tests for host-specific differences. A passing local connection proves only that one client, configuration, and authorization path worked once.

What MCP Server Developers Should Do Next

Most August changes landed in clients, authentication flows, discovery systems, or enterprise controls around servers that may already be protocol-correct. Treat client compatibility as a regression target rather than a one-time integration check.

Start with authentication, but keep the paths distinct. Test pre-registered clients in Cline, Goose, and Claude Code. Test issuer binding and credential resolution in Codex. If you support managed enterprise deployments, test Claude's identity-provider flow separately. Then work through the timeout, discovery, content-fidelity, and policy cases for the clients your users actually run.

MCPJam can run these cases against a controlled server with request traces, OAuth debugging, cross-client comparison, a model in the loop, and CI integration.

Test your MCP server with MCPJam

Frequently Asked Questions

Will dynamic client registration stop working?

Not immediately. The MCP 2026-07-28 revision deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, but retained it for backward compatibility. Keep dynamic registration working while adding the registration mechanisms your target clients and enterprise deployments require.

What should I retest first after August's MCP client updates?

Start with authentication. Test pre-registered clients in Cline, Goose, and Claude Code, issuer and credential handling in Codex, and enterprise-managed authorization in Claude. Then test hang and timeout isolation. If you distribute through AgentCore or GitHub Copilot, add registry and allowlist coverage before release.

How do I debug an MCP server that hangs in one client but works in another?

Capture a protocol trace at the failure boundary. Cline, Claude Code, and Codex shipped different timeout, isolation, or discovery behavior in August, so the same slow server can fail, retry, or succeed depending on the client and configuration.

Reproduce the same operation across clients and compare the exact request, response, timing, reconnect behavior, and final server state. That comparison tells you whether the failure comes from the server's timing or from a host-specific lifecycle policy.