Skip to content

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

Closed

Description

@huandao-gonglu

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.

Activity

  1. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    mcpIssues related to the use of model context protocol (MCP) servers
    app-serverIssues involving app server protocol or interfaces
    on Apr 22, 2026
  2. huandao-gonglu commented on Apr 22, 2026

    @huandao-gonglu
    Author

    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.

  3. Attys-syttA commented on Apr 24, 2026

    @Attys-syttA

    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.

  4. Attys-syttA commented on Apr 24, 2026

    @Attys-syttA

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    app-serverIssues involving app server protocol or interfacesbugSomething isn't workingextensionIssues related to the VS Code extensionmcpIssues related to the use of model context protocol (MCP) serverswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions