fix: stdio MCP transport never created a session, breaking musehub_set_context's session focus (musehub#210)
musehub_set_context's own returned message tells every connecting agent to call it once and then omit owner/slug on subsequent calls -- the documented, intended workflow. The dispatcher's session-focus injection (_handle_tools_call, dispatcher.py) was never broken: it correctly writes to session.repo_focus and correctly injects it into the next call's arguments when owner/slug are absent. The bug was entirely in musehub/mcp/stdio_server.py -- every handle_request() call passed session=None (the implicit default), so musehub_set_context's write was a silent no-op (guarded by an is-not-None check on ctx.session), and the next musehub_read_context() call had no session to inject owner/slug from, resolving to an empty-string repository lookup.
The Streamable HTTP transport never had this problem: it creates an MCPSession right after a successful initialize and threads it through every subsequent request via the Mcp-Session-Id header. stdio has no such header, but it IS a single, long-lived connection to exactly one client for the process's lifetime -- so the fix creates one session at the same moment HTTP does (right after a successful initialize) and reuses that same object for every request thereafter, for as long as the process runs.
Extracted the capability-extraction + create_session() logic HTTP already had (_create_session_from_initialize in api/routes/mcp.py) into a shared musehub.mcp.session.create_session_from_initialize_params(), used by both transports now instead of duplicating it.
Semantic Changes
28 symbols
Files Changed
+1
~3
1110 in snapshot
0 comments
muse hub commit comment sha256:64298d820f83e03ad4a1d3dae5a5fe2e57d124c1ebd0d56e99d93e69b595dccc --body "your comment"
No comments yet. Be the first to start the discussion.