CLI 1.5.47: on a 401 the interactive CLI starts npx -y mcp-remote with no version pinned, in every OAuth profile we tested #13429

What happens

@continuedev/cli 1.5.47 is the current release on npm. When isAuthError classifies an error as authentication, an interactive session falls back to npx -y mcp-remote <server-url> in MCPService.ts. The predicate covers HTTP 401 and 405 and any error message containing "401", "405" or "Unauthorized". Headless mode skips this branch.

The package name carries no version. npx uses a project-local or cached copy if there is one, and otherwise the registry's latest. The user never chooses which.

The CLI's MCP transport carries only static headers and a Bearer apiKey. This bridge is therefore the CLI's only OAuth path. It came in with #8143. Source at the pinned commit: MCPService.ts, lines 441 to 474 and mcpUtils.ts, lines 9 to 19.

What we measured

We ran CLI 1.5.47 on Windows against a local synthetic OAuth and MCP server, in four OAuth profiles. They were a public client without dynamic registration, a confidential client without it, a Client ID Metadata Document client, and dynamic registration enabled. A stub npx placed first on PATH recorded its arguments and exited without starting anything.

In all four interactive profiles the CLI answered the first 401 by calling npx with -y mcp-remote http://127.0.0.1:<port>/mcp. That includes the profile with dynamic registration available. The headless run stopped at the authorization challenge without that call. No bridge process ever ran.

Rows and limits are on the connectivity page of MCP Host Matrix, Continue CLI. The recorded arguments are in CONTINUE-ARGV-CHECK.json.

Why it matters

The user configured a remote HTTP server and gets a local Node process from npm that they never named, at a version nobody chose. Five published CVE records on mcp-remote stem from our reports, and CISA-ADP scored them up to 9.8 Critical (advisories). On 15 October 2026 the then-current 0.15.1 still followed the request paths of two of them, CVE-2026-51994 and CVE-2026-51995. No release since, 0.15.2 included, states a fix. Because the bridge is the CLI's only OAuth path, every OAuth-protected server takes this route. Servers that offer dynamic registration take it too.

Asks

1. Use OAuth in the CLI's own MCP path (Continue core already has MCPOauth.ts, which the CLI does not call), and start a bridge only on explicit opt-in.
2. While the fallback stays, pin an exact mcp-remote version and say in the terminal that a bridge is being started.
3. Mention the fallback in the CLI MCP documentation.

Limits. One CLI build, one OS, a synthetic provider. The stub caught the launch, so what the bridge would have done was not measured. We reported the source-level fallback privately on 10 October 2026. There was no response as of 25 October.