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
When opencode refreshes an OAuth token for an MCP server (e.g., Atlassian), it does not include the resource parameter (RFC 9728) in the token refresh request. Atlassian's OAuth server requires the resource parameter to bind the token to the correct audience. Without it, the refreshed token is rejected with HTTP 401 by the MCP endpoint.
A fresh token obtained manually with the resource parameter works correctly (returns 400 for protocol reasons, not 401 for auth). But once opencode auto-refreshes the token, it breaks again.
This differs from #22095 (which is about webfetch, not MCP OAuth refresh).
Plugins
Atlassian MCP (remote OAuth)
OpenCode version
1.17.11
Steps to reproduce
Configure Atlassian MCP server with OAuth
Complete initial OAuth flow (works)
Wait for token to expire (or restart opencode)
opencode refreshes token without resource parameter
If you believe your issue is distinct (e.g., the resource parameter omission is a separate bug from the refresh not being triggered), please clarify so maintainers can track them separately.
I traced this against current dev and the version reported here (1.17.11). OpenCode 1.17.11 already pins @modelcontextprotocol/sdk 1.29.0; in that SDK, authInternal() passes the selected resource to refreshAuthorization(), and executeTokenRequest() writes it into the form body. A focused invocation produced:
The remaining discriminator appears to be the configured Atlassian endpoint. Atlassian's current documented endpoint, https://mcp.atlassian.com/v1/mcp/authv2, returns a WWW-Authenticate header with resource_metadata, and that metadata declares resource as the same endpoint. The legacy /v1/sse and /v1/mcp endpoints currently return no resource_metadata, and their derived RFC 9728 well-known URLs return 404, so the SDK has no validated resource to add. Current setup guide: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/setting-up-ides/
Could you confirm the exact MCP URL that produced the trace? If it was a legacy endpoint, please retest with /v1/mcp/authv2. If authv2 still omits resource, a redacted token-request trace plus the preceding WWW-Authenticate header would show whether the loss is during metadata discovery or request construction.
I'm using /v1/mcp/authv2. Token refresh is not happening automatically — I'm being re-prompted for auth when the token expires. This suggests the refresh request is being rejected.
Activity
github-actions commentedon Jun 30, 2026
This issue might be a duplicate of existing issues. Please check:
If you believe your issue is distinct (e.g., the
resourceparameter omission is a separate bug from the refresh not being triggered), please clarify so maintainers can track them separately.fengjikui commentedon Jul 10, 2026
I traced this against current
devand the version reported here (1.17.11). OpenCode 1.17.11 already pins@modelcontextprotocol/sdk1.29.0; in that SDK,authInternal()passes the selected resource torefreshAuthorization(), andexecuteTokenRequest()writes it into the form body. A focused invocation produced:The remaining discriminator appears to be the configured Atlassian endpoint. Atlassian's current documented endpoint,
https://mcp.atlassian.com/v1/mcp/authv2, returns aWWW-Authenticateheader withresource_metadata, and that metadata declaresresourceas the same endpoint. The legacy/v1/sseand/v1/mcpendpoints currently return noresource_metadata, and their derived RFC 9728 well-known URLs return 404, so the SDK has no validated resource to add. Current setup guide: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/setting-up-ides/Could you confirm the exact MCP URL that produced the trace? If it was a legacy endpoint, please retest with
/v1/mcp/authv2. Ifauthv2still omitsresource, a redacted token-request trace plus the precedingWWW-Authenticateheader would show whether the loss is during metadata discovery or request construction.SharmilaMohan91 commentedon Jul 13, 2026
I'm using /v1/mcp/authv2. Token refresh is not happening automatically — I'm being re-prompted for auth when the token expires. This suggests the refresh request is being rejected.
github-actions commentedon Sep 12, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.