Windows MCP SSH stdio transport closes after initialize when PROGRAMDATA is missing from inherited environment

[AbarnaaSree]

Description

On Windows, an MCP server launched through the stdio client can terminate shortly after the initialize message when the spawned process is given the SDK's restricted inherited environment.

During investigation of Windows MCP + SSH behavior, I found that PROGRAMDATA is missing from DEFAULT_INHERITED_ENV_VARS in src/mcp/client/stdio.py.

Environment

• Windows 11
• MCP Python SDK
• MCP server launched through stdio
• SSH-based MCP server

Observed behavior

The MCP SSH subprocess can close shortly after the initialize message with a transport-closed error.

The same SSH setup works when launched manually and behaves differently when the expected Windows environment is available.

Investigation

The stdio client constructs a restricted environment for spawned processes.

PROGRAMDATA was not included in the Windows inherited environment list:

DEFAULT_INHERITED_ENV_VARS = (
    [
        "APPDATA",
        "HOMEDRIVE",
        "HOMEPATH",
        "LOCALAPPDATA",
        "PATH",
        "PATHEXT",
        "PROCESSOR_ARCHITECTURE",
        "SYSTEMDRIVE",
        "SYSTEMROOT",
        "TEMP",
        "USERNAME",
        "USERPROFILE",
    ]
    if sys.platform == "win32"
    else ...
)

Adding PROGRAMDATA allows the spawned Windows process to receive this standard environment variable.

Proposed fix

Add:

"PROGRAMDATA",

to the Windows DEFAULT_INHERITED_ENV_VARS list in:

src/mcp/client/stdio.py

Testing

I reproduced the Windows MCP + SSH behavior and investigated the restricted subprocess environment.

After adding PROGRAMDATA:

• Verified that PROGRAMDATA is inherited by the spawned process.
• Tested the restricted environment with Popen.
• Ran the stdio client tests successfully: 25 passed, 8 skipped.
• git diff --check passes.

I have prepared PR #3334 with this change.

Related issue

This investigation was motivated by MCP SSH transport closing immediately after initialize on Windows.

I would appreciate maintainer confirmation that this is the appropriate fix and whether this issue can be assigned to me so PR #3334 can be reopened.

[AbarnaaSree]

I’d like to work on this issue. I’ve already prepared PR #3334 with the proposed fix. Could you please assign this issue to me so the PR can be reopened?