Repository navigation
mcp auth reports success without OAuth on servers with public discovery #55138
Description
Description
On v1.19.0, opencode mcp auth reports authentication success for a remote server whose initialization and tool discovery are public, without browser consent or token exchange. A later protected tool call fails with Unauthorized, but the server remains connected and its tools remain available.
Expected: anonymous discovery stays available; explicit login performs OAuth, and a protected-tool authentication failure exposes needs_auth until login completes. The refused tool call must not be replayed automatically.
Plugins
None required. Reproduced with a synthetic localhost MCP/OAuth server.
OpenCode version
1.19.0; affected implementation is on the maintained v1 branch.
Steps to reproduce
- Configure a remote server with public
initialize/tools/list, OAuth discovery metadata, and protectedtools/callreturning HTTP401 withWWW-Authenticate. - With no stored credentials, run
opencode mcp auth <name>. - Observe “Authentication successful” but no authorization or token requests.
- Make a protected tool call: it fails, while MCP status stays connected.
The accompanying fix includes deterministic local-server regressions for both cases, including background GET401 and auth-disabled behavior. No real identity, user writing or model call is needed.
Screenshot and/or share link
Non-visual authentication/state issue; verified through CLI output and synthetic server request counts.
Operating System
macOS 26.6.2, arm64
Terminal
Native CLI invoked from a shell.
Activity
opencode-agent commentedon Oct 13, 2026
Thanks for the detailed report and the deterministic repro.
This is about OpenCode v1 (1.19.0). v1 now only gets fixes for critical problems (data loss, security issues, crashes or breakage with no workaround), so this is unlikely to be fixed there. The same behaviour was reported in #36946. That issue was closed after maintainers confirmed that the explicit MCP auth flow in OpenCode v2 resolves it. A v1 fix (#53468) was also closed because v1 PRs are no longer accepted.
We'd encourage upgrading to v2 (the
@opencode/clipackage,opencodecommand). Related issues:initialize) #36946: the same problem on v1 (mcp authreports success with no token, then tool calls fail as Unauthorized)If you think this is critical for v1, or you can reproduce it on v2, please reply here with the v2 version and steps and we'll take another look. If you have a v1 patch, it may be worth porting it to v2 and opening a PR against
dev.111mihir commentedon Oct 13, 2026
Thanks for pointing to the existing v2 work. This submission is a backport for the released v1.19.0 implementation, not a claim that the same explicit-login bug remains in v2. I have linked #36946 and the open v2 recovery PR #55013 here for context.
The patch is in #55139. It also updates v1's MCP SDK to 1.32.0 for the published cross-origin redirect advisory (GHSA-6prh-2h8m-c8cw); the existing SDK patch is retained. I understand v1 has a restricted maintenance policy and that this backport may not be accepted. No change to anonymous discovery or automatic replay is proposed.
opencode-agent commentedon Oct 13, 2026
Thanks for clarifying, and for linking #36946 and #55013.
I understand this is a backport for v1.19.0 and not a claim that v2 is affected. As you noted, v1 only gets fixes for critical problems. Here
mcp authwrongly reports success, but the protected call is still refused, so this falls outside that policy. The earlier v1 fix for the same behaviour (#53468) was closed because v1 PRs are no longer accepted. Maintainers can still look at #55139, but this issue is likely to be closed as won't fix for v1.The MCP SDK update for GHSA-6prh-2h8m-c8cw is a separate concern from this bug. If you believe v1 is actually exposed to that advisory, please report it on its own so it can be judged as a security issue, not as part of this MCP auth backport.
Thanks again for the careful repro and for porting the context over.
opencode-agent commentedon Oct 14, 2026
I'm closing this as not planned. The bug (
mcp authreporting success with no OAuth on servers with public discovery) only affects v1, and v1 now only gets fixes for critical problems. This one falls outside that, since the protected call is still refused. The same behaviour was reported in #36946, which was closed after maintainers confirmed v2 fixes it. The related v2 gap where a server stays "Connected" after a 401 is tracked in #53942, with a fix proposed in #55013.Thank you for the careful repro and the backport in #55139. Maintainers can still look at that PR on its own. If you think v1 is exposed to the SDK advisory you mentioned (GHSA-6prh-2h8m-c8cw), please report that separately as a security issue. And if you ever see this behaviour on v2, please open a new issue with the version and steps.