Repository navigation
stderr is not available until after start is called #174
Description
const transport = new StdioClientTransport({
command: argv.command,
args: argv.args,
env: process.env as Record<string, string>,
stderr: 'pipe',
});
const client = new Client(
{
name: "mcp-proxy",
version: "1.0.0",
},
{
capabilities: {},
},
);Here, transport.stderr is gonna be null, which is a problem if the intent is to capture the error messages at the start time.
A somewhat workaround is something like this:
let stderrOutput = '';
try {
console.info('connecting to the MCP server...');
const connectionPromise = client.connect(transport);
transport?.stderr?.on('data', (chunk) => {
stderrOutput += chunk.toString();
});
await connectionPromise;
console.info('connected to the MCP server');
} catch (error) {
console.error('could not connect to the MCP server', error, prefixLines(stderrOutput, '> '));
await setTimeout(1000);
process.exit(1);
}I've used it here punkpeye/mcp-proxy@4933267
Activity
BobDickinson commentedon Mar 25, 2025
I've been pulling my hair out on this for a couple of hours. Thanks for this! I tried every permutation of error event and handler on the client and transport to capture startup failure errors with no luck. It's hard to believe that nobody working on the SDK ever had to debug failed start. Maybe they didn't pipe the transport stderr.
That workaround is scary, but it does work for me also (presumably the connect code sets the transport stderr before it yields).
msfeldstein commentedon Apr 30, 2025
This is extremely annoying for people trying to debug servers that have issues at startup, would love to see this supported by the SDK
Merge pull request modelcontextprotocol#174 from ryanrozich/fix-env-v…
mattzcarey commentedon Sep 11, 2026
Closed as already fixed in PR #437:
StdioClientTransportcreates aPassThroughin its constructor whenstderr: 'pipe', sotransport.stderris available beforestart()and early startup output is captured. See the constructor and getter on main, and the same on v1.x.