Windows MCP stdio server fails when launched via corepack/npx, but works with absolute node.exe + script path

What version of the Codex App are you using (From “About Codex” dialog)?

0.117.0-alpha.24

What subscription do you have?

Using Codex App with a custom API provider / API key setup

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, MCP stdio servers can fail to start correctly in Codex App when configured with shell-resolved commands like corepack or npx, even though the same server works correctly when launched through the official MCP SDK client or when configured with an absolute executable path.

I reproduced this with Panda CSS MCP.

Failing config example:

[mcp_servers.panda]
type = "stdio"
command = "corepack"
args = ["pnpm", "exec", "panda", "mcp", "--cwd", "A:\\code\\Yunhui"]
I also previously tested equivalent variants using npx panda mcp ....

Observed failure in Codex:

MCP startup failed: handshaking with MCP server failed: connection closed: initialize response
Working config example:

[mcp_servers.panda]
type = "stdio"
command = "C:\\Program Files\\nodejs\\node.exe"
args = ["A:\\code\\Yunhui\\node_modules\\@pandacss\\dev\\bin.js", "mcp", "--cwd", "A:\\code\\Yunhui"]
With the absolute node.exe + script path config, Codex App is able to connect and use the Panda MCP tools successfully.

Important comparison:

The Panda MCP server itself is not broken.
I verified that the same server works with the official @modelcontextprotocol/sdk client.
I also verified that Codex App can use the server successfully once I switch to the absolute executable path config.
This suggests a Windows-specific process launching / command resolution issue in Codex App for stdio MCP servers, especially around .cmd / shell shim resolution (corepack, npx, etc.).
Expected behavior:

Codex App should be able to launch stdio MCP servers on Windows using common commands such as corepack or npx, as long as they are resolvable in the user environment.
Actual behavior:

The server fails during MCP initialization unless I bypass shell-resolved commands and use an absolute executable path.
Additional note:

After fixing the launch method, resources/list for Panda returns -32601 Method not found, but that appears to be expected because Panda provides tools rather than MCP resources. The main bug here is the Windows stdio launch behavior, not Panda itself.

What steps can reproduce the bug?

On Windows, MCP stdio servers can fail to start correctly in Codex App when configured with shell-resolved commands like corepack or npx, even though the same server works correctly when launched through the official MCP SDK client or when configured with an absolute executable path.

I reproduced this with Panda CSS MCP.

Failing config example:

[mcp_servers.panda]
type = "stdio"
command = "corepack"
args = ["pnpm", "exec", "panda", "mcp", "--cwd", "A:\\code\\Yunhui"]
I also previously tested equivalent variants using npx panda mcp ....

Observed failure in Codex:

MCP startup failed: handshaking with MCP server failed: connection closed: initialize response
Working config example:

[mcp_servers.panda]
type = "stdio"
command = "C:\\Program Files\\nodejs\\node.exe"
args = ["A:\\code\\Yunhui\\node_modules\\@pandacss\\dev\\bin.js", "mcp", "--cwd", "A:\\code\\Yunhui"]
With the absolute node.exe + script path config, Codex App is able to connect and use the Panda MCP tools successfully.

Important comparison:

The Panda MCP server itself is not broken.
I verified that the same server works with the official @modelcontextprotocol/sdk client.
I also verified that Codex App can use the server successfully once I switch to the absolute executable path config.
This suggests a Windows-specific process launching / command resolution issue in Codex App for stdio MCP servers, especially around .cmd / shell shim resolution (corepack, npx, etc.).
Expected behavior:

Codex App should be able to launch stdio MCP servers on Windows using common commands such as corepack or npx, as long as they are resolvable in the user environment.
Actual behavior:

The server fails during MCP initialization unless I bypass shell-resolved commands and use an absolute executable path.
Additional note:

After fixing the launch method, resources/list for Panda returns -32601 Method not found, but that appears to be expected because Panda provides tools rather than MCP resources. The main bug here is the Windows stdio launch behavior, not Panda itself.

What is the expected behavior?

_No response_

Additional information

_No response_