Sites plugin MCP creates unbounded node/cmd recursion on Windows when VOLTA_HOME is not forwarded

Open 💬 2 comments Opened Jul 16, 2026 by Perfumista
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

26.707.91948 (bundled Codex CLI reports 0.144.5)

What subscription do you have?

Not included; the failure is entirely local and reproduces before any account-dependent operation.

Which IDE are you using?

VS Code 1.129.0

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro)

Additional environment:

  • Bundled Sites plugin: sites@openai-bundled version 0.1.27
  • Volta: 2.0.2
  • Node managed by Volta: 24.14.0

What issue are you seeing?

The bundled Sites plugin can create an unbounded Windows process-spawning loop when Codex starts its stdio MCP server.

The plugin manifest launches a bare Node command:

{
  "mcpServers": {
    "sites-design-picker": {
      "command": "node",
      "args": ["./mcp/server.mjs"],
      "cwd": "."
    }
  }
}

On this machine, node first resolves to Volta's node.exe shim. The Codex plugin/MCP launch inherited the shim-containing PATH but did not forward VOLTA_HOME. Without VOLTA_HOME, the Volta shim resolves node back to itself through cmd.exe, producing this recursive chain:

node.exe (Volta shim)
  -> cmd.exe /C node ./mcp/server.mjs
    -> node.exe (same Volta shim)
      -> cmd.exe /C node ./mcp/server.mjs
        -> ...

The incident reached approximately 13,480 node.exe processes plus 13,484 cmd.exe processes (>27,000 total processes), caused intermittent system freezes and heavy memory compression, and made ordinary process enumeration/termination extremely slow.

The root command and working directory were confirmed as:

node ./mcp/server.mjs
<Codex plugin cache>/openai-bundled/sites/0.1.27/

The Sites server.mjs itself contains no child_process, spawn, exec, or fork calls. The recursion occurs before the real Node runtime executes the server.

What steps can reproduce the bug?

A contained Windows Job Object reproduction confirms the root cause without allowing the process tree to escape:

  1. Install Volta on Windows and place its shim directory first on PATH.
  2. Install Node through Volta (24.14.0 in this reproduction).
  3. Enable the bundled Sites plugin 0.1.27.
  4. Launch the Sites MCP command with the shim-containing PATH but with VOLTA_HOME removed:
set VOLTA_HOME=
node ./mcp/server.mjs
  1. Observe alternating Volta-shim node.exe and cmd.exe /C node ./mcp/server.mjs descendants.

Measured in a bounded Job Object after three seconds:

VOLTA_HOME present:
  stable; reaches the real Node 24.14.0 executable

VOLTA_HOME absent:
  83 active descendants after 3 seconds
  alternating node.exe (Volta shim) and cmd.exe
  never reaches the real Node executable

Direct real Node executable:
  stable MCP server process

The production incident matched the VOLTA_HOME absent chain exactly.

What is the expected behavior?

Codex should start one stable Sites MCP process using the selected real Node runtime. A malformed launcher environment must not be able to create an unbounded descendant tree.

Additional information

Suggested primary plugin fix:

{
  "mcpServers": {
    "sites-design-picker": {
      "command": "node",
      "args": ["./mcp/server.mjs"],
      "cwd": ".",
      "env_vars": ["VOLTA_HOME"]
    }
  }
}

The Codex MCP documentation already supports forwarding local environment variables via env_vars for stdio servers.

More robust alternatives/safeguards:

  1. Avoid relying on a bare tool-manager shim for a bundled local MCP server; launch through a known runtime or resolve the real executable before starting the server.
  2. Ensure plugin-provided stdio MCP servers can explicitly forward required non-secret toolchain variables such as VOLTA_HOME.
  3. On Windows, place each MCP server in a Job Object configured to kill all descendants on startup failure/timeout.
  4. Add a process-growth/startup guard so a server that does not complete MCP initialization cannot create thousands of descendants before the normal startup timeout fires.

Temporary user mitigation is disabling sites@openai-bundled or ensuring VOLTA_HOME is forwarded before the plugin MCP starts.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32690

Powered by Codex Action

starise · 1 month ago

Confirmed on a newer Windows desktop build and newer bundled Sites plugin.

Environment:

  • Codex/ChatGPT app build: 26.715.61943
  • Bundled Sites plugin: sites@openai-bundled 0.1.30
  • Windows: Microsoft Windows NT 10.0.26200.0 x64
  • Volta-managed Node: v24.18.0
  • VOLTA_HOME in the normal terminal environment: C:\Users\Andrea\scoop\apps\volta\current\appdata

Observed immediately after opening the desktop app with Sites enabled:

  • 789 Node/Node REPL processes at the first sample
  • 1,146 after 12 seconds (roughly 30 new processes/second)
  • command line: node C:/Users/Andrea/.codex/plugins/cache/openai-bundled/sites/0.1.30/mcp/server.mjs
  • process chain repeatedly alternated cmd.exe /C node .../server.mjs and node.exe
  • attempting to kill only the Node children did not help because the chain recreated them immediately

Mitigation and verification:

  1. Set [plugins."sites@openai-bundled"] enabled = false.
  2. Kill both cmd.exe and node.exe descendants whose command line matched the Sites MCP server.
  3. Process count returned to one unrelated node.exe and one stable node_repl.exe.
  4. Monitored for another 10 seconds: the Sites process-chain count remained exactly zero.

This confirms that the issue still reproduces with Sites 0.1.30; it was not fixed by the updates from 0.1.27. The normal shell has VOLTA_HOME, so this remains consistent with the app/plugin launch environment failing to forward it.