Windows Codex Desktop MCP tool wrapper reports `Transport closed` while same stdio server works directly

What version of Codex is running?

Codex Desktop for Windows, observed process package version: OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0.

What subscription do you have?

Plus

Which model were you using?

GPT-5 Codex desktop session.

What platform is your computer?

Windows, PowerShell shell. Unity Editor is running locally.

What issue are you seeing?

A configured MCP server for Unity is reachable and works when launched directly, but Codex Desktop's built-in MCP tool namespace fails immediately with Transport closed.

The failing Codex tool call is any mcp__unity__ call, for example:

unity_list_instances -> tool call error: tool call failed for `unity/unity_list_instances`
Caused by: Transport closed

This persists after restarting Codex multiple times and after restarting the Unity-side MCP server from within Unity. Claude is able to use the same MCP connection successfully on the same machine.

This may be related to, but appears narrower/different from, #7155. In this case the direct stdio MCP server is healthy and the latest failed Codex wrapper calls do not appear to reach the Unity MCP server log at all.

MCP server config

From ~/.codex/config.toml:

[mcp_servers.unity]
command = "node"
args = ["C:/Users/<user>/Projects/unity-mcp-server/src/index.js"]
env = { UNITY_HUB_PATH = "C:/Program Files/Unity Hub/Unity Hub.exe", UNITY_PORT_RANGE_START = "7890", UNITY_PORT_RANGE_END = "7899", UNITY_BRIDGE_TIMEOUT = "60000" }

[mcp_servers.unity.tools.unity_editor_ping]
approval_mode = "approve"

[mcp_servers.unity.tools.unity_editor_state]
approval_mode = "approve"

[mcp_servers.unity.tools.unity_list_instances]
approval_mode = "approve"

[mcp_servers.unity.tools.unity_select_instance]
approval_mode = "approve"

[mcp_servers.unity.tools.unity_agents_list]
approval_mode = "approve"

The server package is anklebreaker-unity-mcp; package.json says 2.28.1, while the MCP server reports serverInfo.version: 2.26.0.

Steps to reproduce

1. On Windows, configure Codex Desktop with a local Node MCP server using newline-delimited JSON-RPC over stdio.
2. Start Unity with the Unity MCP bridge listening in the range 7890-7899.
3. In this repro, Unity is on port 7892.
4. From Codex Desktop, call a configured MCP tool such as unity_list_instances or unity_editor_ping.
5. Observe immediate Transport closed from the Codex MCP tool wrapper.
6. Launch the exact same server command manually and send newline-delimited MCP JSON-RPC messages over stdio.
7. Observe that direct MCP calls succeed.

Expected behavior

Codex should keep the MCP stdio transport open and return the tool result, matching the direct MCP client behavior and Claude's behavior on the same machine.

Actual behavior

Codex reports Transport closed immediately from the MCP tool wrapper. After the first failure, repeated mcp__unity__ calls continue to fail immediately.

Evidence collected

Raw Unity TCP port is open:

Test-NetConnection -ComputerName 127.0.0.1 -Port 7892
# TcpTestSucceeded: True

Unity MCP instance registration exists:

[
  {
    "port": 7892,
    "projectName": "CosmicCatastrophe",
    "projectPath": "C:/Users/<user>/Projects/cosmic-catastrophe/CosmicCatastrophe",
    "unityVersion": "6000.4.2f1",
    "platform": "WindowsEditor",
    "processId": 43084,
    "isClone": false,
    "cloneIndex": -1
  }
]

Direct MCP server launch and newline-delimited stdio handshake succeeds:

MCP_RESPONSE {"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{},"resources":{}},"serverInfo":{"name":"unity-mcp","version":"2.26.0"}, ...},"jsonrpc":"2.0","id":1}

Direct tools/call for unity_list_instances succeeds:

{
  "instances": [
    {
      "port": 7892,
      "projectName": "CosmicCatastrophe",
      "projectPath": "C:/Users/<user>/Projects/cosmic-catastrophe/CosmicCatastrophe",
      "unityVersion": "6000.4.2f1",
      "isClone": false,
      "cloneIndex": -1,
      "source": "portscan",
      "isSelected": false
    }
  ],
  "totalCount": 1,
  "selectedPort": null,
  "selectedProject": null
}

Direct tools/call for unity_editor_ping succeeds:

{
  "connected": true,
  "status": "ok",
  "unityVersion": "6000.4.2f1",
  "projectName": "CosmicCatastrophe",
  "projectPath": "C:/Users/<user>/Projects/cosmic-catastrophe/CosmicCatastrophe",
  "platform": "WindowsEditor",
  "isClone": false,
  "cloneIndex": -1,
  "processId": 43084
}

Unity MCP debug log shows prior successful Codex wrapper attempts reaching the server, but the latest failing calls after restart did not add log entries. That suggests the failure is happening before the configured Node MCP server receives the request.

Additional notes

When I tested the server manually, header-framed MCP messages started the server but did not get responses; newline-delimited JSON-RPC over stdio worked. If Codex Desktop's wrapper is using or falling back to a different stdio framing mode for this server, that could explain the symptom, but this is only an inference from the direct smoke tests.