WSL2/devcontainer: MCP OAuth callback unreachable from host browser (Sentry) #6598

Open
opened 2026-02-16 18:04:42 -05:00 by yindo · 3 comments
Owner

Originally created by @chrisolszewski on GitHub (Jan 17, 2026).

Originally assigned to: @thdxr on GitHub.

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

  1. Configure:
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sentry": {
      "type": "remote",
      "url": "https://mcp.sentry.dev/mcp",
      "oauth": {}
    }
  }
}
  1. Run opencode mcp auth sentry
  2. Complete auth in the host browser
  3. Redirect back to 127.0.0.1:19876 fails / OpenCode keeps waiting.

Operating System

Windows 11 / WSL2 - Ubuntu 24.04

Terminal

Wezterm

Originally created by @chrisolszewski on GitHub (Jan 17, 2026). Originally assigned to: @thdxr on GitHub. ### 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 1. Configure: ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "sentry": { "type": "remote", "url": "https://mcp.sentry.dev/mcp", "oauth": {} } } } ``` 2. Run `opencode mcp auth sentry` 3. Complete auth in the host browser 4. Redirect back to `127.0.0.1:19876` fails / OpenCode keeps waiting. ### Operating System Windows 11 / WSL2 - Ubuntu 24.04 ### Terminal Wezterm
yindo added the windows label 2026-02-16 18:04:42 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 17, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #7377: [FEATURE]: Allow custom OAuth redirect URI configuration for MCP servers
  • #5766: bug: OAuth uses wrong authorization URL and missing redirectUri config
  • #8798: Unable to authenticate ChatGPT with OpenCode web when it's being reverse proxied
  • #8274: /connect doesn't work for openai when server is remote (similar callback networking issue)
  • #7887: opencode mcp auth fails silently in remote/headless sessions (related devcontainer issue)

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.

@github-actions[bot] commented on GitHub (Jan 17, 2026): This issue might be a duplicate of existing issues. Please check: - #7377: [FEATURE]: Allow custom OAuth redirect URI configuration for MCP servers - #5766: bug: OAuth uses wrong authorization URL and missing redirectUri config - #8798: Unable to authenticate ChatGPT with OpenCode web when it's being reverse proxied - #8274: /connect doesn't work for openai when server is remote (similar callback networking issue) - #7887: opencode mcp auth fails silently in remote/headless sessions (related devcontainer issue) 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.
Author
Owner

@chrisolszewski commented on GitHub (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.

@chrisolszewski commented on GitHub (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.
Author
Owner

@j-token commented on GitHub (Jan 20, 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.

@j-token commented on GitHub (Jan 20, 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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6598