Skip to content

Windows Desktop 26.623 starts duplicate MCP pools after RefreshMcpServers on hidden thread #30753

Open
Open
Windows Desktop 26.623 starts duplicate MCP pools after RefreshMcpServers on hidden thread#30753
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverswindows-osIssues related to Codex on Windows systems

Description

@aidawilliam41-ops
aidawilliam41-ops
opened on Jun 30, 2026

Summary

On Windows Codex Desktop, a clean app start spawned four near-complete MCP helper pools within the first minute. Local logs show four RefreshMcpServers submissions in the startup window: three were sent to a non-visible/hidden session loop, and one to a visible pinned thread.

This looks related to the MCP refresh lifecycle area fixed/covered by #29608, but this report adds a Windows Desktop case where duplicate MCP stdio helper pools appear immediately after startup, not after a long-running session.

Environment

  • Product: Codex Desktop App on Windows
  • App package: OpenAI.Codex 26.623.9142.0
  • Bundled/local CLI observed from the Desktop runtime path: codex-cli 0.142.4
  • OS: Windows 11 x64
  • Shell in Codex thread: PowerShell
  • App server command shape:
    • codex.exe app-server --analytics-default-enabled
  • MCP configuration location:
    • %USERPROFILE%\.codex\config.toml

Observed behavior

After a clean Windows restart and launching Codex Desktop, before running any deliberate user workload in that session, the app server spawned multiple MCP helper sets.

Process creation timestamps showed four MCP batches around:

20:59:09
20:59:20
20:59:28
20:59:35

The repeated pools included local stdio MCP helpers such as:

node_repl.exe
node.exe ./mcp/server.mjs --stdio       # codex-security
github-mcp-server.exe
morph-mcp
firecrawl-mcp
tavily-mcp
playwright-mcp
shadcn mcp
figma-developer-mcp
valyu

A later process snapshot still showed multiple instances of the same MCP helper classes, including four node_repl and four codex-security stdio server processes.

RefreshMcpServers evidence

In the startup window 20:58:00..21:01:30 local logs_2.sqlite contained exactly four RefreshMcpServers submissions:

RefreshMcpServers rows in startup window: 4
by_thread:
  hidden/non-visible thread 019f19af-... : 3
  visible pinned WiaiKit thread          : 1

46537615 20:59:14 DEBUG codex_core::session::handlers hidden-thread sub=019f19af-6a38-...
46537765 20:59:15 DEBUG codex_core::session::handlers hidden-thread sub=019f19af-702c-...
46538447 20:59:23 DEBUG codex_core::session::handlers hidden-thread sub=019f19af-8ea8-...
46538450 20:59:23 DEBUG codex_core::session::handlers visible-thread sub=019f19af-8eb9-...

The hidden/non-visible thread had only four exact-thread log rows in the checked DB:

20:59:09 shell_snapshot for hidden thread
20:59:14 RefreshMcpServers
20:59:15 RefreshMcpServers
20:59:23 RefreshMcpServers

The hidden thread did not appear through the app thread-list API, did not appear in the persisted Desktop global state file, and did not have a matching session file under %USERPROFILE%\.codex\sessions.

A separate hidden thread seen later was identified as a Memory Writing Agent and is not the cause of the startup MCP batches.

Things ruled out locally

  • The user's config.toml does not contain duplicated MCP server definitions. It has one configured set of local MCP servers.
  • Desktop saved-project/pinned-thread state validated cleanly:
    • ShapeOk=True
    • SavedRootsOk=True
    • ProjectOrderOk=True
    • PinnedOk=True
  • The duplicate MCP process groups were spawned by the main Desktop app-server parent process, not by a user shell script.
  • The repeated RefreshMcpServers submissions are visible in logs_2.sqlite, so this is not only a Task Manager display issue.
  • No secrets or token values were printed or included in this report.

Expected behavior

After a clean Desktop startup, Codex should not launch several full duplicate pools of stdio MCP helper processes for the same MCP configuration.

If MCP refresh is triggered for loaded threads during startup, old/superseded managers should be shut down and their stdio helper processes should exit. Hidden/internal threads should also not cause repeated full MCP pool creation unless those pools are actually needed and lifecycle-owned.

Actual behavior

Codex Desktop launched multiple MCP helper pools shortly after startup. The local evidence points to repeated RefreshMcpServers submissions, mostly targeting a hidden/non-visible thread, with the stdio MCP helpers remaining alive.

Related issues / PRs

Impact

  • Large process count immediately after startup.
  • Extra memory/process overhead from duplicate stdio MCP helpers.
  • Confusing diagnostics: the visible UI shows only normal threads, while the refreshes target at least one hidden/non-listable session loop.
  • Potentially affects Browser/Chrome/Computer Use workflows because node_repl is one of the duplicated MCP helpers.

Suggested investigation area

  • App-server startup MCP refresh scheduling.
  • Hidden/internal thread registration in ThreadManager and whether it participates in queue_best_effort_refresh.
  • Whether RefreshMcpServers can be queued multiple times for the same hidden thread during startup/plugin/account reconciliation.
  • Whether the Desktop build includes the Shut down superseded MCP managers on refresh #29608 cleanup behavior and whether cleanup covers the hidden/internal session case.

Notes

I can provide a more detailed sanitized evidence pack privately if needed. The raw local evidence includes logs_2.sqlite excerpts, process parent/child snapshots, and a sanitized list of MCP server names, but I did not attach raw logs publicly because they may contain local paths and unrelated thread metadata.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    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 Jun 30, 2026

  2. github-actions commented on Jun 30, 2026

    @github-actions
    github-actionsBot
    on Jun 30, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. aidawilliam41-ops commented on Jul 1, 2026

    @aidawilliam41-ops
    aidawilliam41-ops
    on Jul 1, 2026 – with ChatGPT Codex Connector
    Author

    Additional diagnostics after a controlled debug restart (Windows Codex app):

    Environment:

    • Codex Windows app package path: OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0
    • app-server command observed: codex.exe app-server --analytics-default-enabled
    • OS shell: PowerShell
    • One active visible thread after restart: Codex glodal; several other threads are idle / notLoaded.

    Controlled restart procedure:

    1. Captured process snapshot.
    2. Stopped Codex app/app-server plus Codex-owned MCP wrapper processes.
    3. Temporarily set RUST_LOG=codex_core=debug,codex_app_server=debug,codex_mcp=debug,info and a temporary log_dir.
    4. Relaunched the Codex Windows app via AppsFolder AppID.
    5. Waited ~120 seconds and captured a second process snapshot.
    6. Restored config.toml and cleared user-level RUST_LOG.

    Result: the duplicate MCP process issue reproduced immediately after the restart and became more obvious.

    Process counts before restart:

    • Codex.exe: 8
    • codex.exe: 1
    • cmd.exe MCP wrappers: 28
    • node.exe: 28
    • node_repl.exe: 2

    Process counts after restart:

    • Codex.exe: 8
    • codex.exe: 1
    • cmd.exe MCP wrappers: 56
    • node.exe: 56
    • node_repl.exe: 4

    Grouped MCP process counts after restart:

    • firecrawl: 8
    • tavily: 8
    • morph: 8
    • playwright: 8
    • figma: 8
    • shadcn: 8
    • valyu: 4
    • node_repl: 4
    • app-server ./mcp/server.mjs: 4

    Interpretation:

    • This does not look like a single orphaned Node process.
    • It looks like multiple full MCP pools being started within one Desktop session.
    • The restart did not collapse the pool to one instance; it produced 4x / 8x repeated MCP instances depending on server.

    Log observations after restart from logs_2.sqlite:

    • TRACE/DEBUG logging did appear in SQLite.
    • No plaintext codex-tui.log appeared in the temporary log_dir.
    • Post-restart SQLite level counts in the observed window: TRACE=1892, DEBUG=74, INFO=55, WARN=13.
    • codex_mcp::connection_manager rows in the observed window: 336.
    • WARNs observed were not direct MCP duplication errors; they included:
      • Shell snapshot not supported yet for PowerShell
      • template-creator manifest warning: ignoring interface.defaultPrompt: maximum of 3 prompts is supported

    I kept local diagnostic artifacts under:

    • C:\Codex\diagnostics\codex-debug-restart-20260701-091836

    I am not attaching raw logs because they may contain local paths/session metadata, but I can provide a sanitized subset if maintainers want a specific format.

  4. aidawilliam41-ops commented on Jul 1, 2026

    @aidawilliam41-ops
    aidawilliam41-ops
    on Jul 1, 2026 – with ChatGPT Codex Connector
    Author

    Update after a newer Windows Desktop build and a clean restart.

    This still reproduces on my machine after updating from the earlier 26.623.9142.0 build to:

    Codex Desktop package: OpenAI.Codex 26.623.11225.0
Codex CLI: codex-cli 0.142.5
OS: Windows 11 x64
Shell in thread: PowerShell
App server command: codex.exe app-server --analytics-default-enabled

    codex doctor --summary still reports the installation as healthy:

    Codex Doctor v0.142.5 · windows-x86_64
mcp: 11 server (9 stdio, 2 streamable_http) · 0 disabled
17 ok | 1 idle | 1 notes | 0 warn | 0 fail ok

    However, immediately after restarting Codex Desktop, a single Desktop app-server spawned multiple identical MCP helper pools.

    Sanitized process summary:

    APP_SERVER_COUNT=1
APP_SERVER pid=<redacted> parent=Codex.exe created=2026-07-01 11:58:19

Initial direct MCP-like children: 50
Later direct MCP-like children: 60

Buckets under the same app-server:
2026-07-01 11:58:47 count=10
2026-07-01 11:58:49 count=10
2026-07-01 11:59:03 count=10
2026-07-01 11:59:21 count=10
2026-07-01 12:00:15 count=10
2026-07-01 12:02:52 count=10

    Each bucket contained the same ten MCP helpers:

    codex-security
figma_framelink
firecrawl
github
morph
node_repl
playwright
shadcn
tavily
valyu

    Duplicate command-line groups were also visible, for example 5x / 6x instances of the same MCP launch command for morph, playwright, figma-developer-mcp, firecrawl, shadcn, tavily, valyu, codex-security, and node_repl.

    Additional local checks:

    • codex mcp list shows one unique configured set of MCP servers, not duplicated config entries.
    • The duplicate processes are direct children of the one Desktop app-server, not child processes of a user shell script.
    • The app thread list showed only the current visible thread as active; other relevant visible threads were idle or notLoaded.
    • Two session/thread ids seen in fresh startup shell-snapshot warnings were not returned by the app list_threads API, which still points toward hidden/internal session-loop participation.
    • Running the local selfcheck script did not itself create the initial 5 pools; they were already present before it ran. One additional duplicate pool appeared later during continued Desktop activity.

    Recent log warnings seen in the same run included:

    codex_core_plugins::manifest: ignoring interface.defaultPrompt: maximum of 3 prompts is supported
codex_core::shell_snapshot: Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

    Those warnings may be unrelated, but the duplicate MCP pool behavior is reproducible after a clean Desktop restart on 26.623.11225.0.

    No raw logs, SQLite files, token values, local usernames, or private project paths are included here. I can provide a fuller sanitized evidence pack privately if helpful.

  5. wherewolf87 commented on Jul 13, 2026

    @wherewolf87
    wherewolf87
    on Jul 13, 2026

    Current-version data point: Windows package 26.707.8479.0 still produced three distinct Codex-owned Node/MCP batches shortly after app-server startup:

    09:03:08 to 09:03:20: 25 node.exe + 1 node_repl.exe
09:03:53 to 09:04:13: 27 node.exe + 1 node_repl.exe
09:05:27 to 09:05:38: 31 node.exe + 1 node_repl.exe

    The app-server began at 09:02:12. All 86 Node-family processes remained live together and held about 7.74 GiB working set. This temporal signature is consistent with repeated startup/session refresh pools, although process timing alone does not prove which internal refresh event owned each batch.

    Full sanitized process evidence is in #32797.

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

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingmcpIssues 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