openai / openai/codex

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

Open
#38,572 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug mcp performance skills windows-os
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

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.
  6. Continue normal task switching or tool use.
  7. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the build-ios-apps plugin manifest and its MCP definition, then trace Codex's MCP startup path for Windows platform checks. Reproduce with the listed PowerShell process inventory and verify that XcodeBuildMCP is not created on Windows, unsupported functionality reports a macOS requirement, and incompatible process groups are bounded or reaped.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, rust
Domain
devtools, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.