MCP subprocess stderr and logging notifications are not surfaced in VS Code

[ormasoftchile]

Summary

A stdio MCP server launched by copilot-runtime emits lifecycle and watcher logs, but the VS Code MCP: <server> Output channel remains empty.

Environment

• macOS arm64
• VS Code using the bundled copilot-runtime
• Local stdio MCP server launched with stdin/stdout/stderr pipes

Reproduction

1. Configure a local stdio MCP server in VS Code.
2. Have the server write startup and runtime messages to stderr, flushing each line.
3. Start or restart the MCP server.
4. Select its MCP: <server> channel in the VS Code Output panel.
5. Trigger additional runtime messages, such as a filesystem watcher event.

Actual behavior

The Output channel remains empty.

Process inspection confirms:

• The MCP child process has stderr connected to a pipe.
• copilot-runtime owns and reads the other end of that pipe.
• Running the same MCP executable directly displays every stderr line immediately.
• MCP notifications/message logging notifications are also accepted by the transport but are not rendered in the Output channel.

This indicates the messages are lost between copilot-runtime and the VS Code UI rather than inside the MCP server.

Expected behavior

The SDK/runtime should forward MCP child stderr to the server's VS Code Output channel. If MCP logging capability is advertised, notifications/message events should also be surfaced or exposed through an SDK event so the host can render them.

Additional note

The MCP process continues serving tools normally; only observability is missing. This makes watcher/reindex failures effectively invisible even though the server is logging them.

[ormasoftchile]

Correction to my original report: SDK responsibility was not established. Investigation found removal of centralized MCP protocol log forwarding in the server and an EBADF error when the server supervisor attempted to close an already-closed stdin. Restoring protocol log forwarding and using EOF stdin via /dev/null passes production stdio tests for tool logs and watcher create/modify/delete indexing. This report should not be treated as evidence of an SDK defect.