-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Note: I wasn't sure if this is a bug report or a feature request. It's a critical "protocol oversight."
Is your feature request related to a problem? Please describe.
Currently there is no way in the protocol to identify an individual conversation in order to isolate state. This is a current hazard for any stateful server that is capable of running over stdio when used by a stdio client that multiplexes multiple conversations' tool calls over the single stdio channel, such as Claude Desktop.
Many servers have a notion of setting working directory or project root. Imagine this scenario: Conversation A sets git working directory to the project discussed in that conversation. Human user switches to another conversation. Conversation B sets git working directory to a different directory. Human returns to the conversational context set up in conversation A and suggests performing git reset --hard. Neither the human nor the AI have obvious visibility into the fact that the git working directory has changed underneath them.
Describe the solution you'd like
The protocol should require a per-message globally-unique conversation identifier for stdio transports, possibly in a well-known/reserved key inside _meta. I think that it would be best suited as a MUST sort of thing, but even a SHOULD statement with an implementation in Claude Desktop would meet my needs.
Describe alternatives you've considered
Punt this to the Claude Desktop implementation instead of addressing it in the protocol, by process-isolating each conversation. This presents slightly more overhead in the host machine and slightly more process management for Claude Desktop, but keeps the protocol from having to uniquely identify conversations over stdio. Or punt this to Claude Desktop and have it provide a _claude_desktop_conversation_id: uuid-uuid-uuid-uuid in _meta without any protocol level changes.
Additional context
This is both an ergonomics issue as a server developer (I want to be able to store arbitrary state in a session store keyed by a unique identifier that represents the conversation), but it also is a safety hazard as described above, because existing servers treat stdio as representing a single AI conversation