[Windows ARM64] build-ios-apps launches and retains macOS-only XcodeBuildMCP process trees

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

OpenAI Codex MSIX 26.810.4967.0, ARM64.

What subscription do you have?

ChatGPT subscription. The exact tier is not relevant because the failure occurs in local plugin/MCP startup before any model request.

What platform is your computer?

Windows 11 Pro ARM64, build 28000.

System Node.js: v24.14.1, arm64.

What issue are you seeing?

The installed build-ios-apps plugin 0.1.2 unconditionally launches XcodeBuildMCP on Windows:

npx -y xcodebuildmcp@latest mcp

Xcode and the supported Apple simulator toolchain are unavailable on Windows. However, the plugin manifest contains no platform declaration, and its MCP definition has no OS gate.

Under one unchanged Codex Desktop app-server, five complete XcodeBuildMCP process generations accumulated over approximately four and a half hours. The app-server itself did not restart.

Each retained generation contained this process chain:

cmd.exe /c npx -y xcodebuildmcp@latest mcp
  node.exe ... npx-cli.js -y xcodebuildmcp@latest mcp
    cmd.exe /c xcodebuildmcp mcp
      node.exe ... xcodebuildmcp/build/cli.js mcp

Observed generation times relative to app-server startup:

+00:36  generation 1
+01:02  generation 2
+03:01  generation 3
+04:20  generation 4
+04:29  generation 5

Current memory snapshot:

| Scope | Processes | Working set | Private memory |
| --- | ---: | ---: | ---: |
| XcodeBuildMCP, 5 generations | 20 | 18.7 MiB | 1,121.5 MiB |
| Complete Codex Desktop tree | 75 | 1,867.9 MiB | 6,401.1 MiB |
| Primary app-server | 1 | 141.0 MiB | 1,317.1 MiB |

Most XcodeBuildMCP private memory had already been paged out because the 16 GiB system was under memory pressure. The low working set therefore does not mean the helpers are harmless: they retain about 1.1 GiB of private commit and contribute to paging.

No Xcode or iOS tool was needed for the observed Windows work. A platform-incompatible MCP should not be started merely because its plugin is installed or a new tool context is created.

This is narrower than the generic MCP lifecycle problem. Even if helper reuse and teardown were perfect, XcodeBuildMCP should never be launched on Windows.

What steps can reproduce the bug?

1. Install or enable build-ios-apps in Codex Desktop on Windows.
2. Fully start Codex Desktop and keep one app-server alive.
3. Open or resume normal tasks and use several tool contexts. Do not request Xcode or iOS simulator work.
4. Inspect descendants of the packaged codex.exe app-server.
5. Observe one or more retained chains containing:

npx -y xcodebuildmcp@latest mcp.

1. Continue normal task switching or tool use.
2. Observe additional XcodeBuildMCP generations under the same app-server.

A minimal Windows inventory command is:

Get-CimInstance Win32_Process |
  Where-Object CommandLine -Match 'xcodebuildmcp' |
  Select-Object ProcessId, ParentProcessId, Name, CreationDate, CommandLine

What is the expected behavior?

• build-ios-apps must declare and enforce a macOS platform requirement for Xcode-backed MCP functionality.
• Codex must reject or disable XcodeBuildMCP before process creation on Windows.
• Skills that remain useful without Xcode may stay available, but their Xcode MCP dependency must remain disabled.
• Failed or idle platform-incompatible MCP process groups must be reaped at a bounded lifecycle boundary.
• Codex should not repeatedly execute an unpinned @latest npm launcher on an unsupported platform.

A user-facing diagnostic should report that XcodeBuildMCP requires macOS instead of silently retaining helper processes.

Additional information

The active plugin package contains:

• a plugin manifest with no platform restriction;
• an MCP definition whose command is npx;
• arguments -y xcodebuildmcp@latest mcp.

Related but broader: #37672 tracks large-scale Windows code-mode/MCP helper fan-out and configuration handling. This report is intentionally limited to the missing Windows platform gate and retained XcodeBuildMCP trees.

A sanitized current-build process snapshot was also added to #37672 for correlation: https://github.com/openai/codex/issues/37672#issuecomment-5293738303

No task IDs, project names, usernames, local paths, prompts, credentials, or raw logs are included.