Repository navigation
ClientSession: add public API for updating callbacks after initialization #2379
Description
Activity
@dgenio looking to do my first contribution inside github, can I take this task?
@dgenio looking to do my first contribution inside github, can I take this task?
Sure, go ahead! I'm not a maintainer so I'm not sure if they agree with this proposal
I thought you were, I think I'll better wait for it to be approved
- added a commit that references this issue
on Apr 9, 2026 - addedenhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supportedP3Nice to haves, rare edge casesNice to haves, rare edge casesneeds decisionIssue is actionable, needs maintainer decision on whether to implementIssue is actionable, needs maintainer decision on whether to implement
on Aug 14, 2026 dgenio commented
on Sep 16, 2026 AuthorMore actionsRe-checking this after the v2 rewrite: I believe the underlying issue is still relevant, although the right API may be slightly different from the original proposal.
On current
main,ClientSessionstill storessampling_callback,elicitation_callback, andlist_roots_callbackprivately. The high-levelClientexposes these as public fields, but_build_session()copies them into theClientSessionwhen the connection is established, so changing them while the client is connected does not affect the live session.One distinction that seems important in v2 is replacing callback behavior vs changing advertised capabilities.
Callbacks participate in client capability advertisement, so enabling a callback after negotiation (or disabling one that was advertised) could leave the negotiated capability state inconsistent. But replacing the implementation of a callback for a capability that is already enabled seems like a valid runtime operation.
Would maintainers be open to a public API for that narrower operation?
For example, either:
session.set_elicitation_callback(callback) session.set_sampling_callback(callback) session.set_list_roots_callback(callback)
with clearly documented capability semantics, or public mutable callback properties / another indirection mechanism.
I'm happy to prepare a fresh v2-native PR once there is agreement on the intended API.
For the original FastMCP roots use case, I think FastMCP can also avoid callback replacement by keeping a stable callback backed by mutable roots state, so I no longer see that particular case as requiring an SDK change. The broader runtime callback-replacement API still seems useful, particularly for elicitation/sampling and the v2 multi-round-trip flow.
Problem
ClientSessionaccepts callback parameters (list_roots_callback,sampling_callback,elicitation_callback) at initialization, but provides no public API to update them after the session is created.This means any client that needs to change callbacks at runtime (e.g., updating roots in response to user action) must mutate private attributes like
_list_roots_callbackdirectly — which is fragile and couples consumers to implementation details.Use case
A client connects to a server with initial roots, then the user changes the working directory or project context. The client needs to update its roots callback so that the next
roots/listrequest from the server reflects the new roots. Today this requires:The same issue applies to
_sampling_callbackand_elicitation_callback.Proposed solution
Add public setter methods on
ClientSessionfor updating callbacks after initialization. For example:Or alternatively, make the callback attributes public (without the leading underscore).
Context
This came up while fixing PrefectHQ/fastmcp#326 —
Client.set_roots()wasn't updating the live session because it only modified pending kwargs. The fix (PrefectHQ/fastmcp#3714) mutates_list_roots_callbackdirectly with a comment noting the fragility. A public API would make this safe and stable.