feat(mcp): add OAuth redirect URI configuration for MCP servers

[christso]

Summary

Re-implements the redirectUri option for MCP OAuth configuration, allowing users to specify a custom callback URL for OAuth flows.

• Adds redirectUri config option to McpOAuth schema
• Updates McpOAuthProvider to use custom redirect URI when provided
• Updates McpOAuthCallback.ensureRunning() to support custom port/path
• Adds parseRedirectUri() utility function

Key difference from original PR #7379: The OAuth callback server is now started lazily in startAuth() only when authentication is actually needed, rather than preemptively in create() for all remote servers. This fixes the regression where non-OAuth MCP servers would fail to connect.

Closes #7377

Test plan

• Existing MCP tests pass (6 tests)
• New parseRedirectUri tests pass (3 tests)
• New ensureRunning with custom redirectUri test passes (1 test)
• Manual test: Context7 remote MCP server connects without OAuth callback server
• Manual test: Local filesystem MCP server connects normally

Manual test results

┌  MCP Servers
│
●  ✓ context7 connected
│      https://mcp.context7.com/mcp
│
●  ✓ filesystem connected
│      npx -y @modelcontextprotocol/server-filesystem /tmp
│
└  2 server(s)

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[egze]

Thanks for the PR. I am directly affected that I can't set a custom redirectUri.

[christso]

Here's the configuration that Claude Code supports when I run claude mcp add -h. OpenCode should also support defining the callback port or URI.

Options:
  --callback-port <port>       Fixed port for OAuth callback (for servers requiring pre-registered redirect URIs)
  --client-id <clientId>       OAuth client ID for HTTP/SSE servers
  --client-secret              Prompt for OAuth client secret (or set MCP_CLIENT_SECRET env var)
  -e, --env <env...>           Set environment variables (e.g. -e KEY=value)
  -H, --header <header...>     Set WebSocket headers (e.g. -H "X-Api-Key: abc123" -H "X-Custom: value")
  -h, --help                   Display help for command
  -s, --scope <scope>          Configuration scope (local, user, or project) (default: "local")
  -t, --transport <transport>  Transport type (stdio, sse, http). Defaults to stdio if not specified.

It's been a while since I submitted the PR because I was happy with the workaround of running a script to copy the MCP token from CC to OpenCode. But it seems a lot of my colleagues are not happy with the workaround, so I'm revisiting this.

Risk analysis

This is a v2 of #7379, which was reverted due to a regression where the OAuth callback server was started eagerly in create() for all remote servers, causing non-OAuth MCP servers (e.g. Context7) to fail.

The regression is fixed in this version. The key change is lazy initialization -- ensureRunning() is now only called inside startAuth(), which is only triggered when OAuth authentication is actually needed. Non-OAuth servers never call startAuth(), so they are unaffected.

Theoretical race condition in the stop/restart logic is not a practical concern. The code stops and restarts the callback server when ensureRunning() is called with a different port/path, which clears all pending OAuth callbacks. However, authenticate() is user-initiated and sequential -- a user would have to be mid-OAuth-flow for one server and simultaneously trigger OAuth for a second server with a different redirectUri. The single-threaded event loop and the interactive nature of OAuth (browser redirect, user action) make this effectively impossible in normal usage.

Ready to merge. @rekram1-node

[christso]

Lazy initialization fix for the regression in #7379 -- this stop/restart path is only reachable during an active OAuth flow (via startAuth()), so non-OAuth servers are never affected. The theoretical race with concurrent different-redirectUri auths is not a practical concern since authenticate() is user-initiated and sequential.