›_ Codex Issues
Codex Issues / #18965

VS Code extension leaks and duplicates local stdio MCP processes on Windows

Resolved 💬 4 comments Opened Apr 22, 2026 by huandao-gonglu Closed Apr 22, 2026
💡 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?

openai.chatgpt-26.417.40842 (bundled codex-cli 0.122.0-alpha.13)

What subscription do you have?

Personal paid ChatGPT plan

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200 x64

What issue are you seeing?

On native Windows, the VS Code Codex extension appears to leak and duplicate local stdio MCP server processes.

I have a single configured local MCP server:

[mcp_servers.my-mcp]
command = 'E:\WORK\myMcp\.venv\Scripts\python.exe'
args = ['E:\WORK\myMcp\server.py']

Observed behavior:

  1. Old codex.exe app-server --analytics-default-enabled processes remain alive after previous VS Code extension sessions/windows.
  2. Those stale app-server processes keep their MCP child processes alive.
  3. If I manually kill the stale Python children, the stale app-server processes respawn them.
  4. A single fresh app-server can also start the same configured MCP server more than once.

This causes the same local MCP server to accumulate multiple orphaned process trees over time.

What steps can reproduce the bug?

  1. Configure one local stdio MCP server in ~/.codex/config.toml:
[mcp_servers.my-mcp]
command = 'E:\WORK\myMcp\.venv\Scripts\python.exe'
args = ['E:\WORK\myMcp\server.py']
  1. Start the Codex VS Code extension and use a workspace that has this MCP enabled.
  2. Open/close VS Code windows or restart the extension a few times.
  3. Inspect processes on Windows, for example with:
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match '^(python|pythonw|codex)(\.exe)?$' } |
  Select-Object ProcessId,ParentProcessId,Name,CommandLine,CreationDate |
  Sort-Object Name,CreationDate | Format-List

What I observed:

  • stale codex.exe app-server processes from older sessions remain alive
  • those stale parents keep or respawn the MCP child processes
  • one fresh app-server can spawn the same MCP server twice

Example of one fresh extension process spawning the same configured MCP twice:

19236 codex.exe app-server --analytics-default-enabled
├─ 38708 "E:\WORK\myMcp\.venv\Scripts\python.exe" E:\WORK\myMcp\server.py
│  └─ 44412 "D:\ProgramData\miniconda3\python.exe" E:\WORK\myMcp\server.py
└─ 23156 "E:\WORK\myMcp\.venv\Scripts\python.exe" E:\WORK\myMcp\server.py
   └─ 45180 "D:\ProgramData\miniconda3\python.exe" E:\WORK\myMcp\server.py

What is the expected behavior?

For a single configured stdio MCP server, I would expect:

  • at most one live MCP process tree per live app-server owner
  • MCP child processes to exit when their owning app-server or VS Code session exits
  • stale app-server processes not to remain alive and not to respawn old MCP children

Additional information

Extension version: openai.chatgpt-26.417.40842
Bundled extension Codex binary: codex-cli 0.122.0-alpha.13
OS: Microsoft Windows NT 10.0.26200 x64

Notes:

  • The duplicate/leaked process ownership looks like the main bug.
  • The nested two-Python chain (.venv\python.exe -> miniconda3\python.exe -> server.py) may be environment-specific, but even if that part is expected, the extension still appears to be leaking and duplicating MCP process trees on Windows.
  • I can provide a fuller before/after process dump with PIDs and timestamps if needed.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18881
  • #17115
  • #17832
  • #17574

Powered by Codex Action

huandao-gonglu · 4 months ago

Closing as a duplicate of #18881.

I added the Windows / VS Code extension reproduction details there so the discussion stays consolidated under the root-cause issue.

Attys-syttA · 4 months ago

Adding another reproduction/data point rather than opening a duplicate issue. #19338
I am seeing what looks like the same issue with the current VS Code ChatGPT/Codex extension on Windows.

Extension:
openai.chatgpt-26.5422.21459-win32-x64

OS:
Windows 11 / Microsoft Windows NT 10.0.26200 x64

Configured MCP server:
[mcp_servers.serena]
command = "uvx"
args = [
"--from",
"git+https://github.com/oraios/serena",
"serena",
"start-mcp-server",
"--context",
"codex"
]

There is only one [mcp_servers.serena] entry in ~/.codex/config.toml, and I do not have a separate Serena/MCP entry in VS Code user/workspace settings.

Observed process tree:

codex.exe app-server --analytics-default-enabled
-> uvx.exe --from git+https://github.com/oraios/serena serena start-mcp-server --context codex
-> uv.exe tool uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context codex
-> serena.exe start-mcp-server --context codex

codex.exe app-server --analytics-default-enabled
-> uvx.exe --from git+https://github.com/oraios/serena serena start-mcp-server --context codex
-> uv.exe tool uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context codex
-> serena.exe start-mcp-server --context codex

Both uvx.exe processes had the same parent codex.exe app-server process.

In the same snapshot, another MCP server (xcodebuildmcp) also appeared twice under the same codex.exe parent, so this does not look Serena-specific. It looks like duplicate MCP initialization by the VS Code extension / app-server.

After manually stopping both Serena processes and starting one manually, only one Serena process tree remained, so the duplicate appears to come from the extension/app-server startup path.

Attys-syttA · 4 months ago

Additional confirmation / control test:

The duplicate MCP startup appears to be tied to the VS Code Codex extension / codex.exe app-server lifecycle, not to Serena or local stdio MCP servers generally.

In the VS Code Codex session, the active app-server was:

codex.exe ProcessId=33180

Under that same app-server, duplicate local stdio MCP process trees were observed for:

  • Serena MCP
  • @modelcontextprotocol/server-filesystem E:\codex_works
  • xcodebuildmcp@latest mcp

For filesystem MCP, two identical process trees were observed:

  • cmd.exe -> node.exe -> cmd.exe -> node.exe
  • cmd.exe -> node.exe -> cmd.exe -> node.exe

Both were started with:

@modelcontextprotocol/server-filesystem E:\codex_works

As a control test, I kept VS Code open and started command-line Codex separately. That created a separate host:

codex.exe ProcessId=37740

Under command-line Codex, each local stdio MCP server started only once:

  • Serena: uvx.exe 7896 -> uv.exe 39340 -> serena.exe 9308
  • filesystem: cmd.exe 31204 -> node.exe 28948 -> cmd.exe 36092 -> node.exe 28428
  • xcodebuildmcp: cmd.exe 29544 -> node.exe 15916 -> cmd.exe 34876 -> node.exe 35576

So far, the evidence suggests:

  • VS Code Codex extension / app-server: duplicate MCP startup
  • command-line Codex: no duplicate MCP startup in the same environment

This makes the issue look specific to the VS Code extension / app-server MCP lifecycle rather than a Serena-specific or filesystem-specific problem.