You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: MCP auth configuration for multi-tenant serve deployments #5784
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
When running OpenCode in serve mode for multi-tenant deployments, all sessions share the same static MCP server configuration. This means MCP servers cannot distinguish which user/session is making a request, making it impossible to implement proper access control at the MCP layer.
Use Case
We're building a platform where multiple users interact with OpenCode through its HTTP API. Each user should only be able to access their own resources via MCP tools (e.g., their own files, databases, or external service credentials).
Currently, the MCP configuration is read once at startup:
We have a similar multi-tenant use case but need to go one step further.
Not only do we need per-session auth headers, we need per-session MCP
server lists — different users should see different MCP servers entirely
based on their role.
A more complete solution would be supporting a full mcp config in
POST /session (not just mcpAuth), which would cover both use cases:
Activity
github-actions commentedon Dec 19, 2025
This issue might be a duplicate of existing issues. Please check:
opencode serverapi #5256: [FEATURE]: Adding Authentication toopencode serverapiFeel free to ignore if none of these address your specific case.
priyankpaladiya commentedon May 15, 2026
We have a similar multi-tenant use case but need to go one step further.
Not only do we need per-session auth headers, we need per-session MCP
server lists — different users should see different MCP servers entirely
based on their role.
A more complete solution would be supporting a full
mcpconfig inPOST /session (not just
mcpAuth), which would cover both use cases:Related: #6822 (agentId in POST /session)