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

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.