Remote MCP OAuth
When Codex runs on a server, MCP OAuth can fail for a simple reason: the browser callback points to local `127.0.0.1`, but the login process that needs that callback is running somewhere else.
The Short Version
Hosted MCP providers such as Vercel or Supabase can use OAuth to authorize Codex. In a remote setup, Codex starts the OAuth flow on the server while your browser opens on your laptop. That split is where `connection refused` and `connection reset` usually come from.
ShipGlows Pattern
ShipGlows reads the callback port from the current OAuth attempt, opens an SSH `-L` route for that port, lets the browser finish the authorization, then closes the tunnel.
Why It Breaks
OAuth localhost callbacks are normal for command-line tools. They become confusing only when the command-line tool is remote and the browser is local.
The problem is not OAuth itself. The problem is routing: the local browser needs a path back to the callback listener running on the remote server.
`codex mcp login vercel` or `codex mcp login supabase` runs on the server because that is where the remote Codex session and its MCP configuration live.
The provider opens an authorization URL in your browser. That URL eventually redirects to `http://127.0.0.1:PORT/callback`.
The callback port is not stable. A later login attempt can use a different port, so reusing an old SSH tunnel is the wrong model.
ShipGlows does not replace the provider flow. It only creates the missing route from the local browser back to the remote callback listener for the duration of the login.
Mental Model
The MCP provider and OAuth state belong to the Codex session on the server, so the login command must run there.
The operator still approves access in the browser, using the provider's official OAuth page.
The tunnel exists only so the local `127.0.0.1:PORT/callback` request can reach the remote listener for that one login attempt.
Once Codex verifies the OAuth status, the callback tunnel is no longer useful. It should not become a permanent app tunnel.
Flow
The browser receives the provider callback on localhost after the operator approves access.
ShipGlows opens a short-lived path between that localhost callback and the matching port on the remote server.
The remote Codex process receives the callback and completes the MCP provider login.
After Codex verifies the OAuth status, ShipGlows closes the callback route instead of keeping a permanent tunnel.
Operator Setup
The important operator detail is not the OAuth URL itself. It is the saved SSH target. If you change servers, the local ShipGlows menu needs the new host, SSH user, and optionally the key path if your key has a custom name.
Run `urls`, then choose the server configuration entry. The same saved connection is used by app tunnels and by `shipglows-mcp-login`.
If `~/.ssh/config` or your SSH agent already selects the right key, ShipGlows does not need a key path. If the key has a special file name and SSH cannot infer it, enter the path in the menu.
The callback port is extracted from the current Codex login output. Manual port reuse is fragile because each OAuth attempt can produce a new callback port.
The browser approval still happens on the provider's official page. The operator chooses the account and organization there.
Security Boundary
ShipGlows should not read, persist, or transform OAuth tokens. The token exchange stays between Codex and the provider. ShipGlows's job is to make the network path match the remote execution model.
The OAuth tunnel should close after the login attempt. Development app tunnels and MCP login tunnels are separate concerns.
OAuth authorization URLs are shown only because the operator needs to open them. Persisted OAuth credentials remain Codex/provider responsibility.
ShipGlows Local Setup
The operational command is `shipglows-mcp-login vercel`, `shipglows-mcp-login supabase`, or `shipglows-mcp-login all`. If the SSH target changed, configure the new server through the local menu first.