please consider temporary back-compat or clearer error; rmcp stdio client: handshake fails on legacy `notifications/message` ({level,message})

Do you mind sharing the MCP spec that has "message" instead of "data"? The 2024-11-05 spec is the same as today. I'm not saying you're wrong but I'd like to refer to a spec for reference and complete understanding here.

https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/logging#log-message-notifications

Do you mind sharing the MCP spec that has "message" instead of "data"? The 2024-11-05 spec is the same as today. I'm not saying you're wrong but I'd like to refer to a spec for reference and complete understanding here. https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/logging#log-message-notifications

Thanks for the clarification, you’re right. I wasn’t claiming there was a spec version that used message. This is about interoperability: some servers (e.g., nx-mcp over STDIO) still emit notifications/message with {level, message}, and the Codex (rmcp stdio client) closes the connection during the handshake.

Example of what I receive from the server (STDIO) and what Codex logs:

# server notification as received over STDIO
{"jsonrpc":"2.0","method":"notifications/message",
 "params":{"level":"info","message":"Using local Nx package at /path/to/workspace/node_modules/nx/src/daemon/client/client.js"}}

# Codex error (excerpt)
Failed to parse message decode: {"method":"notifications/message","params":{"level":"info","message":"..."},"jsonrpc":"2.0"}
Error: data did not match any variant of untagged enum JsonRpcMessage
input stream terminated

My suggestion: surface a more precise diagnostic, because I currently just see “transport closed” on startup. A message like notifications/message: expected params.data, got params.message would make it much easier for users and server authors while the ecosystem fully converges on the spec.

Got it. I'll leave this open to improve the error message rather than to update any actual compatibility. Sound good?

Got it. I'll leave this open to improve the error message rather than to update any actual compatibility. Sound good?

It sounds incredible.

mcp now can connect and discover tool in 0.52 version however the actual tool call still failed

   Caused by:
          tools/call failed: Transport closed

mcp now can't connect exact same issue https://github.com/openai/codex/issues/6020, https://github.com/openai/codex/issues/5619

mcp now can't connect exact same issue #6020, #5619

99% of these issues can be resolved with the solution I attached in the issue itself. Check the codex-tui logs and try to adapt the answer to something suitable for rust-sdk. I just don't think this is a problem that the codex-cli developers should be solving; it's more likely that the creators of mcp are writing the contracts incorrectly. I can't speak with certainty, but rather express my perspective. That's how I solve problems like these.

so, after create a shim just configure it in .codex/config.toml like this:

# === MCP servers ===

[mcp_servers.nx-mcp]
command = "node"
args = ["/home/username/.codex/shims/nx-mcp-stdio-shim.js",
        "/home/username/path/to/yourworkspace"]
cwd = "/home/username/path/to/yourworkspace"
startup_timeout_sec = 120
tool_timeout_sec    = 300

So... is anyone working on this issue?

I also can’t use the latest VS Code extension because of this problem, so I’ve been stuck on 0.4.26.
(If I update to 0.4.30 or later, MCP servers fails to initialize and/or calls sometimes get “Transport closed” mid-call, making it far too unstable to use.)

Because the rmcp client even reacts to ordinary node's console.log outputs and causes a “transport closed”, I don’t think this is a problem that everyone should have to work around by writing shims.

I found the real issue. I use third party library and it log to stdout while I run the mcp server.

import { inspect } from "node:util";

type StdoutConsoleMethod = "log" | "info" | "debug";

const STDOUT_METHODS: StdoutConsoleMethod[] = ["log", "info", "debug"];

let stdoutSanitized = false;

function formatValue(value: unknown): string {
	if (typeof value === "string") {
		return value;
	}

	try {
		return inspect(value, { depth: 5, breakLength: 120, compact: false });
	} catch {
		return String(value);
	}
}

/**
 * MCP STDIO transports expect stdout to contain JSON-RPC only.
 * Third-party libraries (like @ast-grep) occasionally log to stdout,
 * which corrupts the stream. This helper re-routes console.log/info/debug
 * to stderr so MCP clients keep a clean transport channel.
 */
export function ensureMcpStdoutIsQuiet(): void {
	if (stdoutSanitized || process.env.MCP_ALLOW_STDOUT_LOGS === "true") {
		return;
	}

	stdoutSanitized = true;

	for (const method of STDOUT_METHODS) {
		const original = console[method].bind(console);
		console[method] = ((...args: unknown[]) => {
			if (process.env.MCP_ALLOW_STDOUT_LOGS === "true") {
				original(...args);
				return;
			}

			if (args.length === 0) {
				return;
			}

			const message = args.map(formatValue).join(" ");
			process.stderr.write(`${message}\n`);
		}) as typeof console[StdoutConsoleMethod];
	}
}

call ensureMcpStdoutIsQuiet() before you start your mcp server will fix the issue.

This feature request has received few upvotes in the past three months, so I'm going to close it.