
mcp-remote exposed to OS command injection
mcp-remoteConnect an MCP Client that only supports local (stdio) servers to a Remote MCP Server, with auth support:
Note: this is a working proof-of-concept but should be considered experimental.
So far, the majority of MCP servers in the wild are installed locally, using the stdio transport. This has some benefits: both the client and the server can implicitly trust each other as the user has granted them both permission to run. Adding secrets like API keys can be done using environment variables and never leave your machine. And building on npx and uvx has allowed users to avoid explicit install steps, too.
But there's a reason most software that could be moved to the web did get moved to the web: it's so much easier to find and fix bugs & iterate on new features when you can push updates to all your users with a single deploy.
With the latest MCP Authorization specification, we now have a secure way of sharing our MCP servers with the world without running code on user's laptops. Or at least, you would, if all the popular MCP clients supported it yet. Most are stdio-only, and those that do support HTTP+SSE don't yet support the OAuth flows required.
That's where mcp-remote comes in. As soon as your chosen MCP client supports remote, authorized servers, you can remove it. Until that time, drop in this one liner and dress for the MCP clients you want!
All the most popular MCP clients (Claude Desktop, Cursor & Windsurf) use the following config format:
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse"
]
}
}
}
To bypass authentication, or to emit custom headers on all requests to your remote server, pass --header CLI arguments:
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header",
"Authorization: Bearer ${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": "..."
}
},
}
}
Note: Cursor and Claude Desktop (Windows) have a bug where spaces inside args aren't escaped when it invokes npx, which ends up mangling these values. You can work around it using:
{
// rest of config...
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header",
"Authorization:${AUTH_HEADER}" // note no spaces around ':'
],
"env": {
"AUTH_HEADER": "Bearer <auth-token>" // spaces OK in env vars
}
},
npx is producing errors, consider adding -y as the first argument to auto-accept the installation of the mcp-remote package. "command": "npx",
"args": [
"-y"
"mcp-remote",
"https://remote.mcp.server/sse"
]
npx to always check for an updated version of mcp-remote, add the @latest flag: "args": [
"mcp-remote@latest",
"https://remote.mcp.server/sse"
]
mcp-remote listens for an OAuth redirect (by default 3334), add an additional argument after the server URL. Note that whatever port you specify, if it is unavailable an open port will be chosen at random. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"9696"
]
mcp-remote registers as the OAuth callback URL (by default localhost), add the --host flag. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--host",
"127.0.0.1"
]
--allow-http flag. Note: This should only be used in secure private networks where traffic cannot be intercepted. "args": [
"mcp-remote",
"http://internal-service.vpc/sse",
"--allow-http"
]
--debug flag. This will write verbose logs to ~/.mcp-auth/{server_hash}_debug.log with timestamps and detailed information about the auth process, connections, and token refreshing. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--debug"
]
--enable-proxy flag. When enabled, mcp-remote will use the proxy settings from common environment variables (for example HTTP_PROXY, HTTPS_PROXY, and NO_PROXY). "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--enable-proxy"
],
"env": {
"HTTPS_PROXY": "http://127.0.0.1:3128",
"NO_PROXY": "localhost,127.0.0.1"
}
--ignore-tool flag. This will filter out tools matching the specified patterns from both tools/list responses and block tools/call requests. Supports wildcard patterns with *. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--ignore-tool",
"delete*",
"--ignore-tool",
"remove*"
]
You can specify multiple --ignore-tool flags to ignore different patterns. Examples:
delete* - ignores all tools starting with "delete" (e.g., deleteTask, deleteUser)*account - ignores all tools ending with "account" (e.g., getAccount, updateAccount)exactTool - ignores only the tool named exactly "exactTool"30 seconds), add the --auth-timeout flag with a value in seconds. This is useful if the authentication process on the server side takes a long time. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--auth-timeout",
"60"
]
MCP Remote supports different transport strategies when connecting to an MCP server. This allows you to control whether it uses Server-Sent Events (SSE) or HTTP transport, and in what order it tries them.
Specify the transport strategy with the --transport flag:
npx mcp-remote https://example.remote/server --transport sse-only
Available Strategies:
http-first (default): Tries HTTP transport first, falls back to SSE if HTTP fails with a 404 errorsse-first: Tries SSE transport first, falls back to HTTP if SSE fails with a 405 errorhttp-only: Only uses HTTP transport, fails if the server doesn't support itsse-only: Only uses SSE transport, fails if the server doesn't support itMCP Remote supports providing static OAuth client metadata instead of using the mcp-remote defaults. This is useful when connecting to OAuth servers that expect specific client/software IDs or scopes.
Provide the client metadata as a JSON string or as a @ prefixed filepath with the --static-oauth-client-metadata flag:
npx mcp-remote https://example.remote/server --static-oauth-client-metadata '{ "scope": "space separated scopes" }'
# uses node readfile, so you probably want to use absolute paths if you're not sure what the cwd is
npx mcp-remote https://example.remote/server --static-oauth-client-metadata '@/Users/username/Library/Application Support/Claude/oauth_client_metadata.json'
Per the spec, servers are encouraged but not required to support OAuth dynamic client registration.