Cline's CLI rewrites npx mcp-remote <url> into a native Streamable HTTP transport

Kind: idiosyncrasy · Status: current · Last verified: 2026-08-25 · Clients: cline · Revisions: 2025-11-25

resolveNativeMcpTransport runs on every stdio registration the CLI loads. It matches one exact shape and rejects everything else:

A match returns { type: "streamableHttp", url }. Anything else — a flag mcp-remote understands, a proxy invoked some other way, an env entry — is left as stdio and spawned.

The comment gives the reason: Cline has a native Streamable HTTP transport, so running the proxy would duplicate OAuth handling and let a child process open a browser as a side effect of merely enabling the server.

The two surfaces disagree

resolveNativeMcpTransport lives in @cline/core and is called from its config loader and its install path. McpHub validates the settings file against its own schema in apps/vscode/src/services/mcp/schemas.ts, which has no equivalent. The extension spawns the proxy.

The settings file is shared — one file at ~/.cline/data/settings/cline_mcp_settings.json, read by the extension, the CLI and the JetBrains plugin. So a marketplace entry written in the proxy shape produces a subprocess speaking stdio in VS Code and a direct HTTPS connection from the CLI, from the same lines of JSON.

Why it matters for the matrix

The transport a client uses is normally the transport its config names. Here it is not, and the substitution is silent: nothing in the CLI's output says the proxy was skipped.

It also breaks a shortcut worth naming. npx mcp-remote in a config file has been a reliable signal that a client is stdio-only and needs a bridge to reach remote servers. For Cline's CLI it means the opposite — the config predates the native transport, and the client is rewriting around it.

Sources