mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 03:18:23 -05:00
[GH-ISSUE #20208] feat: MCP clients recreated per request, breaking stateful HTTP servers with session IDs #34654
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @adolfoweloy on GitHub (Dec 27, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20208
Check Existing Issues
Verify Feature Scope
Problem Description
Open WebUI creates a new MCP client and calls
initialize()for every chat request, then destroys it afterward. This breaks stateful HTTP MCP servers that return a session ID and expect it to be included in subsequent requests via theMcp-Session-Idheader.Impact: The MCP server returns 400 errors because:
Mcp-Session-IdheaderRoot Cause: MCP clients are request-scoped (created/destroyed per request) instead of session-scoped (created once, reused across requests).
Desired Solution you'd like
For stateful HTTP MCP servers, the client lifecycle should work as follows:
connect()andinitialize()should be called once when the MCP server configuration is loaded at application startupMcp-Session-Idheader for all subsequent requests (tool calls, list operations, etc.)This approach ensures session state is preserved and the MCP server receives the expected session ID on every request after initialization.
Alternatives Considered
Hybrid: Stateful vs Stateless Server Detection
Approach: Detect if an MCP server is stateful (returns session ID) and only use persistent connections for those servers.
Pros:
Cons:
Additional Context
N/A
@owui-terminator[bot] commented on GitHub (Dec 27, 2025):
🔍 Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
#19313 feat: User specific MCP headers
by patrykkozuch • Nov 20, 2025
#19794 MCP OAuth 2.1: Not following WWW-Authenticate → Protected Resource → Authorization Server discovery chain
by jamie-dit • Dec 07, 2025
💡 Tips:
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
@rgaricano commented on GitHub (Dec 27, 2025):
For reference,
Solution Approaches
1. Application-Scoped MCP Client Pool
Create a global MCP client manager that maintains persistent connections:
2. Session ID Extraction and Storage
Modify
MCPClient.connect()to extract and store session IDs:3. Middleware Integration
Update
process_chat_payload()to use the client manager:4. Application Startup Initialization
Initialize the client manager in
main.py:Implementation Steps
This approach maintains session state across requests while preserving the existing tool execution flow
@adolfoweloy commented on GitHub (Dec 28, 2025):
I am closing this issue. It turns out that the session is actually managed by
modelcontextprotocol/python-sdk.@rgaricano commented on GitHub (Dec 28, 2025):
yes, we can leverage the
ctx.sessionobject from themodelcontextprotocol/python-sdkfor mcp session management. Actually current MCPClient creates a ClientSession but doesn't utilize the session context, for use it we need to modify the MCPClientManager to preserve the session context, e.g.:@gmag11 commented on GitHub (Mar 20, 2026):
This is still happening in v0.8.10 and breaks MCP functionality for stateful HTTP MCP servers. A single chat session should reuse the connection with server to keep context valid.
@allarac commented on GitHub (Apr 10, 2026):
I think this is a breaking bug @adolfoweloy. Could this maybe be reopened?