›_ Codex Issues
Codex Issues / #20867

Windows 26.429 desktop becomes unresponsive with long threads, MCP auto-start duplicates, and non-Git workspace warnings

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

Codex Windows 26.429 Feedback

Summary

After updating to Codex Windows version OpenAI.Codex_26.429.3425.0_x64, the desktop app frequently becomes unresponsive on Windows during normal agent-style usage. The issue persists even after disabling most third-party background startup services and disabling browser MCP auto-start.

Environment

  • App: Codex Windows desktop
  • Version observed: OpenAI.Codex_26.429.3425.0_x64
  • OS: Windows
  • RAM: about 16 GB
  • Workspace: D:\
  • Important context: D:\ is used as a broad personal-agent workspace, not as a Git repository.

Symptoms

  1. The Codex UI frequently becomes unresponsive after the app has been open for a while.
  2. Codex.exe renderer, GPU process, and codex.exe app-server can keep consuming CPU even when no external background task is running.
  3. Long conversations make the UI increasingly sluggish. This is especially visible in threads containing many terminal outputs, process tables, and long diagnostic logs.
  4. The renderer appears to struggle with very long thread histories. Scrolling, switching messages, and sending a new message can trigger multi-second hangs.
  5. Earlier in the same setup, browser MCP auto-start caused many duplicated node.exe, chrome-devtools-mcp, @playwright/mcp, watchdog, and temporary Edge processes. This could make the whole system nearly unusable.
  6. After disabling browser MCP auto-start and killing the duplicate helper processes, system memory recovered, but Codex itself still occasionally became unresponsive.
  7. Logs include repeated Git metadata warnings such as Not a git repository, even though the active workspace is intentionally not a Git repository.

UI Rendering Concern

This looks partly like a frontend/rendering performance regression:

  • Long diagnostic conversations with large command outputs appear to degrade the renderer over time.
  • The UI can become unresponsive even when MCP helpers are not running.
  • Renderer CPU remains high after the heavy background processes are stopped.
  • Large preformatted terminal outputs and logs may be causing expensive layout, syntax highlighting, virtualization, or diff/render work.

It would help if long threads used stronger virtualization or collapsed rendering for large terminal outputs, process tables, and logs.

MCP Concern

Browser MCP auto-start should avoid duplicate instances.

Observed repeated helper groups included:

  • chrome-devtools-mcp --autoConnect
  • chrome-devtools-mcp --browserUrl http://127.0.0.1:9222
  • @playwright/mcp
  • chrome-devtools-mcp telemetry watchdogs
  • temporary msedge.exe instances launched by Playwright profiles

The app should either deduplicate MCP processes or expose a clear setting for lazy/manual MCP startup.

Git Metadata Concern

The workspace root D:\ is intentionally not a Git repository. Codex should not repeatedly perform Git metadata work in a way that affects UI responsiveness or fills logs with warnings.

Expected behavior:

  • Detect once that the workspace is not a Git repo.
  • Avoid repeated Not a git repository warning spam.
  • Provide a setting to disable Git metadata scanning for broad personal-agent workspaces.

Expected Behavior

  • Codex should remain responsive in long threads.
  • Large terminal outputs should not make the renderer progressively slower.
  • MCP auto-start should be deduplicated or lazy.
  • Non-Git workspaces should not trigger repeated Git metadata warning loops.
  • Users should have a safe mode or visible toggles for:
  • disabling MCP auto-start,
  • disabling Git metadata scans,
  • reducing long-thread rendering cost,
  • clearing renderer/thread cache without losing the conversation.

Workarounds Tried

  • Disabled third-party startup/background services such as Adobe Creative Cloud, WPS cloud service, WSL service, and other unrelated background helpers.
  • Blocked a runaway Aladdin.exe process that was consuming high CPU.
  • Disabled browser MCP auto-start.
  • Killed duplicated MCP node.exe and temporary Edge processes.
  • Restarted Codex cleanly.
  • Switched default model back to a lighter model.

These mitigations improved system performance, but Codex UI still occasionally became unresponsive, suggesting an app-side renderer/app-server performance problem in this version.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20349
  • #19858
  • #19568
  • #20435
  • #19469

Powered by Codex Action

yixikaiyuannian · 3 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. Codex Desktop accumulates duplicate MCP/helper process trees and multi-GB RSS during UI/debugging workflows #20349 Codex Desktop leaks MCP server processes from internal title-generation sessions on Windows #19858 Codex Desktop renderer CPU loop when projectless/chat root is not a git repository #19568 Codex Desktop renderer spins at high CPU while codex MCP servers are idle #20435 * fix: stdio MCP child process leak causing unbounded memory growth #19469 _Powered by Codex Action_

Thanks. This may indeed overlap with the detected issues.

My local symptoms look like a combination of:

  • #20349: duplicate MCP/helper process trees and multi-GB memory growth
  • #19858: leaked MCP server processes on Windows
  • #19568: renderer CPU loop when the chat/workspace root is not a Git repository
  • #20435: renderer high CPU even while MCP servers are idle

The important detail in my case is that these appear together on Codex Desktop for Windows version OpenAI.Codex_26.429.3425.0_x64.

My workspace root is D:\, intentionally not a Git repository. During the issue, Codex logs repeatedly showed Not a git repository / Git metadata warnings. Earlier, browser MCP auto-start also produced duplicated node.exe, chrome-devtools-mcp, @playwright/mcp, watchdog, and temporary Edge process groups. After disabling MCP auto-start and killing the duplicate helper processes, memory improved, but the Codex UI/renderer still occasionally became unresponsive.

So this issue may be a duplicate, but it seems like a Windows desktop regression where the MCP process leak, non-Git workspace metadata loop, and long-thread renderer performance problems interact.

cedric-albeke · 2 months ago

Adding a current-build data point that may help others mitigate the Desktop freeze / process-tree issue.

Environment:

  • Windows 11 Pro
  • Store package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
  • Symptoms started after the June 1 Store update on this machine

Observed symptoms:

  • Multiple frozen chats; sometimes new chats could not be created.
  • Restarting Codex Desktop did not reliably recover the app; full OS reboot helped temporarily.
  • RAM was not the bottleneck: after reboot there was still ~49 GB free.
  • Process tree showed multiple codex.exe app-server --listen stdio:// instances and node_repl.exe instances.
  • node_repl.exe spawned a child codex.exe app-server --listen stdio://.
  • The security-guidance plugin hook also spawned pwsh -> bash -> wsl chains on tool events, increasing process churn.
  • Windows Error Reporting included Codex.exe / ShellViewReentered around the freeze window.

Mitigations applied:

[plugins."browser@openai-bundled"]
enabled = false

[plugins."security-guidance@claude-plugins-official"]
enabled = false

Then I stopped live node_repl.exe processes and their direct child app-server processes, and reversibly renamed local node_repl.exe binaries under:

%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\node_repl.exe
%LOCALAPPDATA%\OpenAI\Codex\bin\node_repl.exe

After that:

  • No new node_repl.exe process was running.
  • The app became much more stable.
  • Agent task execution became noticeably faster.

Caveat: this disables/breaks internal browser/computer-use automation. Normal Codex Desktop chat and external browsers continued to work.

This looks like the browser/computer-use node_repl path can amplify the broader Desktop process leak / renderer freeze issue on Windows 26.527 builds.

lollipop5371 · 2 months ago

Adding a current Windows build data point from another affected machine.

Environment:

  • OS: Windows 10, build family shown in WER as 10.0.19045.2.0.0
  • Codex Desktop package: OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0
  • Codex.exe file/product version in WER: 149.0.7827.54
  • Shell: PowerShell on Windows
  • Usage pattern: normal Codex Desktop chat/thread switching with several MCP-enabled tools available (cls-mcp, @playwright/mcp, chrome-devtools-mcp)

User-visible symptoms:

  • Codex Desktop intermittently becomes unresponsive when switching conversations.
  • The Windows title bar shows Codex (Not Responding) / Codex (未响应).
  • Sometimes while typing in the composer, the app freezes briefly and the Windows Chinese IME can no longer input Chinese into the composer afterward.
  • A clean restart temporarily restores normal behavior.

Windows Event Viewer evidence from the affected window:

2026-06-11 17:21:22 Windows Error Reporting ID 1001
Event name: AppHangTransient
P1: Codex.exe
P2: 149.0.7827.54

2026-06-11 15:35:30 Windows Error Reporting ID 1001
Event name: RADAR_PRE_LEAK_64
P1: Codex.exe
P2: 149.0.7827.54
P3: 10.0.19045.2.0.0

Before cleanup, process/resource state was highly abnormal:

node.exe count:       152
node.exe WorkingSet:  ~8.9 GB
node.exe Private:     ~10.4 GB

Codex/codex count:    27
Codex/codex WS:       ~1.6 GB

node_repl.exe count:  19

The Codex process tree showed the Store app launching an app-server process, and that app-server had many duplicated helper children. A representative grouping:

codex.exe app-server parent PID 9292
  node_repl.exe children: 19
  node.exe direct children: 19

Command lines in the duplicated helper trees included:

C:\Users\<user>\.codex\scripts\cls-mcp-stdio-proxy.js
npx -y cls-mcp-server
npx @playwright/mcp@latest
npx -y chrome-devtools-mcp@latest
chrome-devtools-mcp telemetry watchdog processes

After fully exiting Codex, killing leftover Codex/node helper processes, and reopening Codex, the same machine returned to a much healthier state:

Codex.exe count:      10, WorkingSet ~964 MB, Private ~934 MB
node.exe count:       8,  WorkingSet ~547 MB, Private ~547 MB
node_repl.exe count:  1,  WorkingSet ~7 MB

No new Codex.exe hang/WER event appeared in the first ~20 minutes after the cleanup/restart.

This looks consistent with a Windows Desktop process lifecycle leak or MCP/helper deduplication issue. The user-facing IME/composer failure appears to be a consequence of the main app/UI thread becoming unresponsive rather than a standalone IME bug.

Expected behavior:

  • Codex Desktop should not accumulate duplicate node_repl.exe, node.exe, MCP proxy/server, Playwright MCP, or Chrome DevTools MCP helper trees across normal thread switching / chat usage.
  • Exiting/restarting Codex should reliably clean up helper processes.
  • The app should remain responsive even after MCP-backed threads have been used repeatedly.
  • If a helper tree is stuck, the app should expose a visible safe cleanup/recovery path rather than requiring manual process cleanup.
HomeHeartTherapy · 2 months ago

Adding a fresh Windows reproduction from a newer Codex Desktop build because this still appears reproducible in current Desktop usage and matches the MCP/app-server lifecycle pattern in this issue, #26327, #20992, and #17115.

Environment

  • Platform: Windows desktop
  • OS reported by .NET: Microsoft Windows NT 10.0.26200.0, x64
  • Codex Desktop package observed in process path: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
  • Backend process observed: codex.exe app-server --analytics-default-enabled
  • Usage pattern: long-running Codex Desktop session, multiple project threads over time, tool/MCP/subagent-heavy work.

User-visible impact

The whole machine became sluggish enough that mouse movement felt floaty/jerky. This was not just Codex UI sluggishness. The workstation had a very high process count, with many Node/Python/MCP helper processes.

Key measurements

Initial live census before cleanup:

  • Total processes: about 1019
  • node.exe: 153
  • python.exe: 133
  • claude.exe: 22
  • codex.exe/Codex.exe: 14
  • Agent/runtime-adjacent target processes: 383

After surgically stopping older exact-duplicate runtime command lines while keeping the newest copy of each command:

  • Settled total processes: 721
  • Target runtime processes: 14
  • Duplicate target runtime command groups: 0
  • Stop requests sent: 74
  • Already exited during cleanup: 7
  • Stop failures: 0

Primary accountable parent before cleanup:

  • codex.exe app-server --analytics-default-enabled
  • It had repeated MCP/runtime child waves over the long-running session.

Exit/reopen comparison

I then captured a pre-exit baseline, fully exited/reopened Codex Desktop, and captured post-reopen measurements.

Pre-exit baseline:

  • Total processes: 541
  • Target runtime processes: 73
  • Duplicate target command groups: 20
  • Codex app-server PID: 221216
  • Codex app-server children: 48
  • Codex app-server runtime children: 46

Post-reopen settled baseline:

  • Total processes: 542
  • Target runtime processes: 73
  • Duplicate target command groups: 20
  • Codex app-server PID: 238820
  • Codex app-server children: 48
  • Codex app-server runtime children: 46

The app-server PID changed across reopen, but the duplicate runtime footprint came back effectively unchanged:

  • target runtime processes: 73 -> 73
  • duplicate command groups: 20 -> 20
  • app-server children: 48 -> 48
  • app-server runtime children: 46 -> 46

There was also a short startup spike during reopen:

  • total processes briefly measured at 1024
  • conhost.exe: 442
  • git.exe: 70

This settled within seconds, so the transient spike may be a separate startup/repo-discovery effect. The durable problem is the repeated MCP/helper runtime set under the new app-server.

Duplicate command pattern

After reopen, repeated groups included multiple copies of the same configured helper commands, for example:

  • node_repl.exe
  • local filesystem MCP server
  • local memory MCP server
  • context7 launcher/server
  • ssh-mcp
  • sentry MCP
  • shadcn / shadcn-ui-docs / tailwindcss MCP servers
  • agent-relay MCP
  • Windows MCP
  • sqlite MCP
  • basic-memory MCP
  • microsoft-onedrive MCP
  • constitutional-guardian MCP

The repeated Python-backed MCP wrappers commonly appeared in groups of 6, and several Node-backed MCP helpers appeared in groups of 3, under the new Codex app-server tree.

Why this seems distinct from ordinary MCP load

This is not just "many MCPs are configured." The concerning observations are:

  1. exact duplicate command lines accumulate in waves;
  2. stopping older duplicate copies materially reduces process count and improves the machine;
  3. exiting/reopening Codex regenerates the same duplicate footprint instead of returning to one helper group per required runtime;
  4. the app-server PID changes, but the helper fan-out count remains the same.

Expected behavior

Codex Desktop should either:

  • reuse one helper/MCP server instance per active runtime/session when appropriate; or
  • reliably terminate helper/MCP process groups when a thread/session/runtime is closed or replaced; and
  • avoid recreating duplicate helper sets on app reopen/resume.

Local evidence retained

I retained local before/after receipts:

  • process snapshots before/after surgical cleanup
  • duplicate runtime parent map
  • termination candidate list
  • stop log
  • pre-exit baseline
  • post-reopen comparison
  • settled post-reopen census

I am not attaching raw JSON publicly because it contains local filesystem paths and full process command lines, but the sanitized counts above come directly from those receipts. I can provide a further-sanitized attachment if useful.