A regression test added to microsoft/agent-framework on September 15 stages an awkward encounter. The first caller signs in; the second asks for a private record. They have separate agent sessions but share one HTTP client. If it saved the first response’s cookie, the second request can arrive wearing the first caller’s identity.
The server is simulated, its private record fictional. The test makes a real architectural problem concrete: starting another agent conversation does not necessarily start another authenticated transport.
On September 15, Microsoft merged a breaking change to its Python integrations that stops internally created HTTP clients from retaining response cookies. It covers MCP tools, agent-to-agent connections, AG-UI chat clients and declarative HTTP workflows. The connection can still be reused. The remote service’s cookie should no longer silently become part of the next request.
The state beneath the conversation
A cookie is a small value a server asks a client to remember and send back. That convenience supports logins, session continuity and routing a user back to the same backend. It becomes a design decision when a reusable client sits underneath several agent runs: who, exactly, owns the remembered state?
The implementation gives framework-created clients a standard Python cookie policy with an empty domain allowlist. There is no eligible domain for a response cookie to enter the jar. The change retains connection pooling and the existing timeout and redirect defaults; it does not solve the problem by opening a fresh connection for every message.
The A2A test preserves the real HTTPX client and its cookie handling while substituting an in-memory server for the network. One run receives a sign-in response with a cookie. A second, separately created agent session asks for the record. The assertions require that the outgoing request carries no cookie and the simulated server denies access. This checks the transport boundary directly, without asking a model to remember which user it represents.
Other tests examine repeated requests, failed responses, explicit cookies and overlapping HTTP work. Those cases matter because a response can leave state behind even when the application treats the request as a failure.
The migration is also a choice about ownership
The new default can break legitimate applications. A service that expects a cookie on its second request may stop recognizing the client—even inside the same MCP session, thread or workflow. Load-balancer affinity can depend on cookies too. The change is broader than clearing state when an agent run ends.
The migration documentation leaves the application an explicit route: supply its own httpx.AsyncClient through http_client=. Declarative workflows accept client= or a client_provider. Caller-supplied clients retain their cookie behavior. They also retain an obligation: the application must scope a cookie-bearing client to the intended authenticated user and close it itself.
One ownership repair accompanies the policy change. A2A previously marked a supplied HTTP client for cleanup in a construction path that also received an A2A protocol client. The new code leaves that HTTP client open. An application relying on the old implicit close has another lifecycle decision to make.
A safer default is a smaller claim than isolation
It would be easy to read the patch as “agent sessions are now isolated.” The documentation explicitly rules that out. Rejecting cookies does not partition an MCP protocol session or other state held by the server. Explicit Cookie headers remain supported. A custom client can still share its jar. In declarative HTTP responses, Set-Cookie headers remain visible; disabling persistence does not redact them.
There is no public incident linked in the pull request, and the regression scenario is not evidence that a real user’s record was exposed. This is a source-level behavior change. At our September 16 check, the newest listed Python release was 1.18.0, published September 10, before the merge. We inspected the diff and tests; we did not run the framework’s integration suite or verify an installed service.
For a team preparing to adopt the change, the useful audit starts below the prompt: identify who creates each HTTP client, which users share it, and whether the remote service depends on remembered cookies. Then exercise two distinct users against a disposable service and inspect the requests. The next release can change the default jar. Only the application can decide whose identity belongs inside it.