Repository navigation
[FEATURE]: Allow custom OAuth redirect URI configuration for MCP servers #7377
Description
Summary
This feature request is focused on adding support for custom OAuth redirect URI configuration for MCP servers.
Problem
OpenCode currently hardcodes the OAuth callback URL as http://127.0.0.1:19876/mcp/oauth/callback. Many OAuth servers (Azure AD, Okta, Keycloak, GitHub OAuth apps, etc.) require exact matching of pre-registered redirect URIs, which prevents users from:
- Using OpenCode with enterprise OAuth providers that use different domains
- Configuring OAuth for deployment scenarios with custom hostnames
- Using Claude Code with different callback port configurations
Design Philosophy
OpenCode already allows overriding the clientId to impersonate different OAuth clients. Since OAuth servers validate both the client ID and the redirect URI as part of the security model, it follows logically that users should also be able to override the redirect URI.
Without this capability, there's an asymmetry where users can point to any OAuth server and any client, but are still constrained by OpenCode's hardcoded callback URL. This defeats the purpose of flexible client configuration.
Therefore, supporting custom redirectUri is essential for feature completeness when users have the ability to override clientId.
Solution
Add a new optional redirectUri configuration parameter to MCP OAuth settings, allowing users to specify custom callback URLs:
{
"mcp": {
"my-server": {
"type": "remote",
"url": "https://api.example.com",
"oauth": {
"clientId": "my-client-id", // Already configurable
"redirectUri": "https://custom.example.com/callback" // NEW: Also configurable
}
}
}
}Implementation Details
- Add optional
redirectUrifield to MCP OAuth config schema - Update OAuth provider to use configured URI when available
- Dynamically configure callback server port/path based on parsed redirect URI
- Fall back to defaults (
http://127.0.0.1:19876/mcp/oauth/callback) when not specified - Full test coverage for custom URI parsing and edge cases
Backward Compatibility
✅ Fully backward compatible - when redirectUri is not specified, uses the default OpenCode callback URL.
Related Issues
This feature was originally part of #5766 which also addressed MCP SDK version updates for authorization endpoint discovery.
Splitting these concerns:
- bug: OAuth uses wrong authorization URL and missing redirectUri config #5766: MCP SDK upgrade (authorization endpoint fix)
- This issue: Custom redirect URI support
Activity
github-actions commentedon Jan 8, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
christso commentedon Jan 8, 2026
PR Created: #7379 - feat: add OAuth redirect URI configuration for MCP servers
This PR implements the feature requested in this issue. Ready for review!
YPares commentedon Jan 12, 2026
If opencode is started in WSL,
127.0.0.1does not work because it doesn't allow to connect to a port in WSL. But usinglocalhostinstead does work.christso commentedon Jan 16, 2026
@rekram1-node Should we rename 127.0.0.1 to localhost as the default? It would fix WSL compatibility and is more standard. Or would you prefer keeping 127.0.0.1 with the redirectUri override option? Or should I create a separate issue to start a discussion?
christso commentedon Jan 17, 2026
@rekram1-node Can you reopen this issue? PR #7379 was reverted in commit 33290c5 due to a regression. I've submitted a new fix in PR #9034 that addresses the original feature request while avoiding the regression.
0x7ffc commentedon Jan 28, 2026
+1 for this
nieomylnieja commentedon Feb 19, 2026
+1 for this, our MCP server cannot be configured with OAuth due to this
renanwilliam commentedon Mar 3, 2026
I have the same situation, but regarding a https scheme issue. My endpoint requires https :/
leoseo-1113 commentedon Mar 23, 2026
I was having a same issue, when putting slack MCP to Opencode. This helped me.
https://github.com/korotovsky/slack-mcp-server
rekram1-node commentedon Apr 9, 2026
been a while sorry yall, @egze pr looks p good, need to verify it. Will test and prolly release it tmr