gemini-cli - 💡(How to fix) Fix StreamableHTTPClientTransport: OAuth token not forwarded to SSE GET request, causing 401 and disconnect [1 participants]

What happened?

When connecting to an OAuth-protected MCP server using httpUrl (Streamable HTTP transport), the initial POST request for initialize succeeds with the stored OAuth token, but the subsequent GET request to open the SSE notification stream (_startOrAuthSse) does not include the Authorization header. The server returns 401 Unauthorized, which tears down the entire connection.

The OAuth flow itself completes successfully — the token is stored in ~/.gemini/mcp-oauth-tokens.json and is valid. The server responds correctly to authenticated POST requests (verified independently via curl). The failure is specifically in the SSE GET sub-request within the Streamable HTTP transport.

Debug output

Found stored OAuth token for server 'myserver'
[MCP error] MCP ERROR (myserver) StreamableHTTPError: Streamable HTTP error: Failed to open SSE stream: Unauthorized
    at StreamableHTTPClientTransport._startOrAuthSse (...)
[MCP error] Error during discovery for MCP server 'myserver': Client is not connected, must connect before interacting with the server. Current state is disconnected

Verification that the server works

The MCP server responds correctly when the token is included manually via curl:

curl -s -X POST https://<server-host>/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

# Returns a valid initialize response with tools capability

Configuration

{
  "mcpServers": {
    "myserver": {
      "httpUrl": "https://<server-host>/mcp"
    }
  }
}

Also tried with url (SSE transport) and with explicit headers containing the Bearer token — same result. The headers config is not forwarded to the SSE GET request either.

Steps to reproduce

1. Configure an MCP server using httpUrl that requires OAuth (supports RFC 8414 discovery) and returns 401 on unauthenticated requests
2. Run gemini — the OAuth flow triggers and completes successfully
3. The CLI stores the token, but the connection attempt fails because _startOrAuthSse() sends a GET without the Authorization header
4. Server returns 401 on the GET, the connection tears down
5. /mcp shows the server as Disconnected
6. Restarting the CLI repeats the same cycle

Root cause

In StreamableHTTPClientTransport, the _startOrAuthSse() method opens a GET request for the SSE notification stream but does not include the OAuth Authorization header that was used for the POST initialize request. The server rejects the unauthenticated GET with 401, causing the transport to disconnect.

What did you expect to happen?

The OAuth token should be included in all requests made by the transport — both POST requests and the GET SSE stream request. The connection should remain established after a successful OAuth flow.

Client information

CLI Version: 0.37.2 (also reproduced on 0.39.0-preview.0)
OS: macOS (darwin 24.6.0)
Auth Method: OAuth (oauth-personal)

Login information

Google Account

Anything else we need to know?

Related issues:

• #18895 — CLI cannot use fresh token in MCP OAuth
• #23776 — MCP servers with OAuth lose authentication when access token expires mid-session
• #6639 — MCP client fails to handle 401 errors correctly for Streamable HTTP Transport (closed/fixed, but different manifestation)

The MCP TypeScript SDK's StreamableHTTPClientTransport supports a custom fetch implementation for propagating auth headers across all requests, but it appears Gemini CLI is not utilizing this for the SSE GET request path.