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]: Allow remote MCP servers to authenticate through an existing integration #53542
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem:
Remote MCP servers may accept the same OAuth credential already managed by an OpenCode integration. Today, each remote MCP server uses an independent OAuth flow, requiring users to sign in repeatedly and duplicating credential refresh and account-switching behavior.
Solution:
Add a native way for a remote MCP server to reference an existing integration for authentication, for example:
The integration should control which destinations may receive its credentials. OpenCode should resolve the active credential through the existing integration lifecycle, apply it to MCP requests, and reconnect when the active account changes.
This should:
reuse one integration sign-in across compatible organizational MCP servers;
avoid storing tokens in MCP configuration;
avoid separate OAuth flows for every server;
fail closed when the integration is unavailable or the destination is not authorized;
preserve existing MCP OAuth behavior when integration authentication is not configured.
I'm volunteering to implement this feature if design considered acceptable;
Some examples of this are LiteLLM and PortKey gateways which serves both LLM and MCP on same endpoint and share OA2/JWT authentication. Currently that requires separate oa2 flows, and as well for custom MCP's with org jwt auth.
To restate it: you'd like a remote MCP server to be able to authenticate with a credential managed by an existing OpenCode integration (e.g. "auth": { "type": "integration", "integration_id": "..." }). One sign-in would then cover several compatible MCP servers, with refresh and account switching handled by the integration, nothing stored in the MCP config, and requests refused when the integration is unavailable or the destination isn't allowed.
At the moment each remote MCP server is registered as its own OAuth integration, keyed by server name and URL, so each server gets its own sign-in. That's why you're asked to sign in repeatedly.
A plugin could get part of the way today: it could read the integration's active credential and add it as an Authorization header with mcp.transform (setting oauth: false). But the token would then sit in the MCP config, refreshed tokens and account switches would only apply after a reload, and there's no way to limit which URLs receive the credential. So it doesn't meet the requirements you listed, and proper support would need changes in OpenCode itself, either in core or in the plugin API.
Activity
github-actions commentedon Oct 6, 2026
This issue might be a duplicate of existing issues. Please check:
bohdanshu commentedon Oct 6, 2026
I'm volunteering to implement this feature if design considered acceptable;
Some examples of this are LiteLLM and PortKey gateways which serves both LLM and MCP on same endpoint and share OA2/JWT authentication. Currently that requires separate oa2 flows, and as well for custom MCP's with org jwt auth.
opencodejr commentedon Oct 27, 2026
Thanks for the detailed proposal, @bohdanshu!
To restate it: you'd like a remote MCP server to be able to authenticate with a credential managed by an existing OpenCode integration (e.g.
"auth": { "type": "integration", "integration_id": "..." }). One sign-in would then cover several compatible MCP servers, with refresh and account switching handled by the integration, nothing stored in the MCP config, and requests refused when the integration is unavailable or the destination isn't allowed.At the moment each remote MCP server is registered as its own OAuth integration, keyed by server name and URL, so each server gets its own sign-in. That's why you're asked to sign in repeatedly.
A plugin could get part of the way today: it could read the integration's active credential and add it as an
Authorizationheader withmcp.transform(settingoauth: false). But the token would then sit in the MCP config, refreshed tokens and account switches would only apply after a reload, and there's no way to limit which URLs receive the credential. So it doesn't meet the requirements you listed, and proper support would need changes in OpenCode itself, either in core or in the plugin API.Maintainers will consider the request.