StdIO transport doesn't detect MCP server process exit and conceals exit code

[mvmn]

Bug description
If MCP server process exits - this is not detected by an StdioClientTransport that launches said process, or any other code. The initialization of MCP server just times out waiting for stdio response from a process that's no longer running

Environment
Spring AI 2.0.0-M5, mcp-core-2.0.0-M2.jar, macOS Tahoe 26.3.1

Steps to reproduce
Configured chrome-devtools MCP server

application.yaml:

spring:
  ai:
    mcp:
      client:
        stdio:
          servers-configuration: classpath:mcp-servers.json

mcp-servers.json:

{
	"mcpServers": {
		"chrome-devtools": {
			"command": "/opt/homebrew/bin/npx",
			"args": [
				"chrome-devtools-mcp@latest",
				"--autoConnect"
			],
			"env":{
				"PATH": "/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin"
			}
		}
	}
}

Without the PATH variable explicitly listing paths, the PATH provided by Spring AI is not sufficient for Node/NPX to launch, the command exits with exit code 127 - which is not detected by Spring AI at all, instead initialize command is sent and response is awaited for default 20 seconds

Expected behavior
In case process exits, there should be no wait for response from it, instead exception should be thrown logging exit code of the process

Minimal Complete Reproducible example
Use above files with this main method in @SpringBootApplication

    public static void main(String[] args) {
        List<McpSyncClient> clients = SpringApplication.run(AiagorcApplication.class, args)
                .getBean("mcpSyncClients", List.class);
        System.out.println("Clients: " + clients.get(0).listTools());
    }

Note: if process exits immediately or quickly, supposedly this can be detected right away in the StdioClientTransport:

			ProcessBuilder processBuilder = this.getProcessBuilder();
			processBuilder.command(fullCommand);
			processBuilder.environment().putAll(params.getEnv());

			// Start the process
			try {
				this.process = processBuilder.start();
			}
			catch (IOException e) {
				throw new RuntimeException("Failed to start process with command: " + fullCommand, e);
			}

			// Validate process streams
			if (this.process.getInputStream() == null || process.getOutputStream() == null) {
				this.process.destroy();
				throw new RuntimeException("Process input or output stream is null");
			}

Debug has shown here the this.process has PID and exit code, but no IOException is thrown - because process ran, it just exited. Alternatively, the input/output streams of exited process are probably closed - and this can be detected in Lambdas created in startInboundProcessing/startOutboundProcessing methods of StdioClientTransport

[DragonFSKY]

Hi @mvmn, I looked into this and traced the lower-level behavior to the MCP Java SDK StdioClientTransport.

The failure path seems to be:

• the stdio process is started successfully by ProcessBuilder.start();
• the process exits before replying to the MCP initialize request;
• the pending initialization request then waits for the request timeout;
• the child process exit code is not propagated to the caller.

That matches the behavior described here, where Spring AI waits for MCP client initialization instead of surfacing the stdio process exit code.

I opened an upstream issue with a smaller reproducer here: modelcontextprotocol/java-sdk#959

I also opened a focused PR for the lower-level SDK behavior here: modelcontextprotocol/java-sdk#960

My understanding is that Spring AI gets this behavior through mcp-core, so the fix should land in the MCP Java SDK first, and Spring AI can then pick it up through the dependency update/verification path.

Please let me know if there is any Spring AI-specific behavior that should also be checked here.

[mvmn]

You are 100% correct
Thank you!