Skip to content

[FEATURE]: MCP OAuth paste-code fallback for headless/SSH sessions #36386

Closed as not planned

Description

@GyeongHoKim

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

On a plain remote/SSH session the OAuth redirect can't reach the local callback listener
at 127.0.0.1:19876. #23951 made the auth URL print to the terminal, but finishing the
flow still needs ssh -L 19876:127.0.0.1:19876. Plenty of setups can't or won't
port-forward.

Proposed solution

A paste fallback: when the browser can't reach the local listener, print the auth URL and
let the user paste the returned code (or the full callback URL) back into the CLI to
finish. Roughly:

$ opencode mcp auth atlassian

┌  MCP OAuth Authentication
│
◇  Couldn't reach a local browser (headless/SSH session).
│
│  Open this URL in any browser and approve access:
│  https://auth.atlassian.com/authorize?response_type=code&client_id=…&state=…
│
◆  Paste the redirect URL (or just the code) from your browser:
│  http://127.0.0.1:19876/mcp/oauth/callback?code=abc123&state=…
│
◇  Authenticated ✔  tokens stored for "atlassian"
└

Prior art: opencode already supports pasting the callback URL back in the terminal for
headless/SSH provider login — e.g. the ChatGPT/Codex OAuth flow from #1686 (see the
remote/headless testing in that thread) and providers.ts. This request is just bringing
that same paste fallback to MCP OAuth. (Claude Code / gh / flyctl do the same for
their logins.)

Relationship to existing work / how I'd approach it

Different solution from #31014 (proxied redirect URL) — this skips callback reachability
entirely. It rides on the listener-free finishAuth path, and since it must bind the
pasted callback to the correct state, it depends on the CSRF hardening in #33725.

Plan: build it on top once #33725 lands; if #33725 is dropped, I'll fold the needed
state-binding into this PR. Happy to take it if the direction sounds good. cc @rekram1-node

Activity

  1. RafitaUTN commented on Aug 3, 2026

    @RafitaUTN

    I can reproduce this with OpenCode v1.18.11 using VS Code Remote-SSH.

    My setup:

    Windows 11
    VS Code Remote-SSH
    Ubuntu Server 26.04
    OpenCode running on the remote host
    Supabase MCP

    The OAuth callback is started on the remote host at 127.0.0.1:<random_port>, but the browser runs on Windows, so the callback is sent to the Windows localhost instead of the remote machine, resulting in ERR_CONNECTION_REFUSED.

    This also affects Vercel MCP.

    VS Code port forwarding does not fully solve the issue because OpenCode uses dynamic callback ports.

    A device authorization flow or a paste-code fallback would make OpenCode usable in Remote-SSH environments.

  2. github-actions commented on Oct 3, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions