[Cross-platform] build-ios-apps starts XcodeBuildMCP on non-macOS hosts in Desktop and VS Code (autogen selfreport from codex)

What versions are affected?

Two independent current reproductions:

What issue are you seeing?

The build-ios-apps plugin starts XcodeBuildMCP on non-macOS hosts where Xcode and Apple simulator tooling cannot exist.

The packaged plugin manifest has no platform declaration. Its MCP definition unconditionally executes:

npx -y xcodebuildmcp@latest mcp

This reproduces through two different Codex clients and two operating systems. Therefore the missing gate is not limited to one Desktop renderer or one OS-specific process launcher.

Reproduction A: Windows Codex Desktop

Environment:

• Windows 11 Pro ARM64, build 28000
• OpenAI Codex Desktop 26.810.4967.0, ARM64
• Node.js v24.14.1, ARM64

Under one unchanged Desktop app-server, five complete XcodeBuildMCP generations accumulated over approximately four and a half hours.

Each generation retained 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

Snapshot:

Most XcodeBuildMCP pages had already been paged out on the 16 GiB host, but the processes still retained about 1.1 GiB of private commit.

Detailed Windows-only report: #38572.

Reproduction B: Linux VS Code extension

Environment:

• Rocky Linux 10.2, x86_64
• VS Code Web with Codex extension 26.810.41047-linux-x64
• Codex CLI/app-server 0.147.0

Two live VS Code extensionHost processes each owned a Codex app-server. Those app-servers retained:

owner app-server 1:  1 XcodeBuildMCP generation
owner app-server 2: 16 XcodeBuildMCP generations
total:              17 generations

Each Linux generation retained two processes:

npm exec xcodebuildmcp@latest mcp
  node .../xcodebuildmcp mcp

Measured Linux snapshot:

The Linux host had no macOS/Xcode capability. The processes were children of VS Code extension app-servers, not a standalone CLI session.

No iOS or Xcode operation is required to trigger the retained helpers. Ordinary task restoration and tool-context activity are sufficient.

Why this needs a plugin/core platform fix

The generic MCP lifecycle issues remain relevant, but lifecycle cleanup alone is insufficient. A macOS-only MCP must not be spawned on Windows or Linux at all.

The fix should be enforced at one or both of these layers:

1. The plugin manifest must declare a supported OS or capability requirement for each MCP server.
2. The Codex plugin loader must reject incompatible plugin MCP definitions before starting a process.

A user-level plugin alias or catalog provenance difference should not determine whether a physically impossible MCP starts. Platform compatibility must be checked after resolving the effective plugin package and before process creation.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows or the Codex VS Code extension on Linux.
2. Have build-ios-apps available through the plugin catalog.
3. Start or restore normal tasks. Do not request iOS, Xcode, or simulator work.
4. Continue normal task switching, tool use, or context creation.
5. Inspect descendants of each Codex app-server.
6. Observe one or more retained xcodebuildmcp@latest mcp process groups.
7. Continue working and observe the generation count and memory grow.

Windows inventory:

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

Linux inventory:

ps -eo pid,ppid,etimes,rss,args |
  grep -E 'xcodebuildmcp(@latest)? mcp'

What is the expected behavior?

• XcodeBuildMCP must be available only on macOS hosts with the required Xcode capability.
• Codex must not start it on Windows or Linux.
• Non-Xcode skills from the same plugin may remain available if they are genuinely portable.
• Unsupported MCP tools should be reported as unavailable without launching npm or Node.js.
• Failed, idle, or superseded MCP process groups must be reaped at a bounded lifecycle boundary.
• Codex should not repeatedly execute an unpinned @latest package on an unsupported platform.
• Plugin diagnostics should show the resolved plugin ID, source, compatibility decision, and owning task/context.

Additional information

Related but not duplicate:

• #38572 is the focused Windows ARM64 / Desktop reproduction.
• #37672 tracks broader Windows code-mode helper fan-out and configuration handling.
• #17574 tracks supported macOS subagent lifecycle leaks involving XcodeBuildMCP.

This issue is specifically about the missing non-macOS platform/capability gate across both Desktop and VS Code extension surfaces.

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

Trace the effective plugin manifest through the plugin loader and MCP process-creation path, focusing on the platform or capability decision before launching xcodebuildmcp. Reproduce with build-ios-apps on Windows or Linux and inspect descendants using the PowerShell or ps commands in the issue. Done means unsupported MCPs are reported unavailable without starting npm or Node.js, while portable skills remain available.