Repository navigation
WSL2/devcontainer: MCP OAuth callback unreachable from host browser (Sentry) #9081
Closed as not planned
Description
Description
OAuth auth for the Sentry MCP server fails for me when OpenCode is running inside WSL2 (or a container/devcontainer) but the browser is on the host.
After auth, the provider redirects to something like http://127.0.0.1:19876/mcp/oauth/callback, but the host browser can’t reach the callback listener inside WSL/container (connection refused / timeout). OpenCode never receives the callback, so the flow doesn’t complete.
Proposed fix
Allow configuring the bind host for the callback listener per server (opt-in, default unchanged). PR #9078 implements this approach.
Note: binding to 0.0.0.0 can expose the callback port; docs should warn. In containers you may also need to publish/forward port 19876.
Plugins
none
OpenCode version
v1.1.25
Steps to reproduce
- Configure:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sentry": {
"type": "remote",
"url": "https://mcp.sentry.dev/mcp",
"oauth": {}
}
}
}- Run
opencode mcp auth sentry - Complete auth in the host browser
- Redirect back to
127.0.0.1:19876fails / OpenCode keeps waiting.
Operating System
Windows 11 / WSL2 - Ubuntu 24.04
Terminal
Wezterm
Activity
github-actions commentedon Jan 17, 2026
This issue might be a duplicate of existing issues. Please check:
These issues all address the core problem of OAuth callback reachability in remote/containerized environments. Feel free to ignore if your specific case requires a different approach.
chrisolszewski commentedon Jan 17, 2026
Bot flagged related issues, but this is about the callback listener’s bind interface. #7377/#5766 focus on redirectUri validation (provider-side), and #8274/#8798/#7887 are about remote/proxy/launch issues. In WSL2/containers, even with a valid redirectUri the host browser can still get "connection refused" if the listener is only bound to loopback. This issue/PR adds an opt‑in bind host to make the listener reachable. Complementary, not duplicate.
j-token commentedon Jan 21, 2026
I’m having the exact same issue.
When authenticating via opencode mcp auth, the same problem occurs, and this issue didn’t happen when I was working on a Mac.
kjbetz commentedon Feb 19, 2026
It looks like there's some work to fix this. As noted in this comment: #7377 (comment)
Changing the callback URL from
127.0.0.1tolocalhostworked for me in getting the Stripe MCP set up and completing the OAuth flow.mattrossman commentedon Feb 26, 2026
I faced this issue running OpenCode through SSH on a remote Ubuntu server—I was unable to authenticate Notion MCP due to the 127.0.0.1 redirect URL.
A workaround is after you complete authentication in the host browser, copy the
/callbackURL from the browser and usecurlon the remote machine to complete the OAuth flow (where127.0.0.1can be resolved).Hopefully the PR mentioned above will make this more streamlined!
github-actions commentedon Apr 28, 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.