Windows Desktop: ChatGPT/Codex processes and Chrome tabs accumulate during local work, causing system-wide slowdown

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

What version of the Codex App are you using (From “About Codex” dialog)?

Current Windows Codex Desktop / ChatGPT Work installation. Exact version was not captured yet and can be added in a follow-up.

What platform is your computer?

Windows (exact OS build and hardware details can be added in a follow-up).

Primary development environment

This is not limited to one unusual workspace layout. My normal Windows development workflow routinely uses all three of the following:

  1. Windows NTFS workspace opened natively by the Windows app
  • Example: C:\Users\wonkw\Obsidian\GotSaeng-OS
  1. The same kind of Windows/NTFS workspace accessed from WSL2 through /mnt/c
  • Pattern: /mnt/c/Users/.../Documents/project
  1. A project stored inside the WSL2 Linux filesystem
  • Linux path pattern: /home/<user>/project
  • Windows UNC example: \\wsl.localhost\Ubuntu\home\devtranger\projects

I switch between these workspace types as part of my primary daily development environment. WSL2 and Windows/WSL filesystem boundaries may be a contributing factor, especially around file watching, path translation, process cleanup, browser/plugin lifecycle, or memory retained by WSL. However, the issue should not be treated as caused by an unsupported or incidental setup: mixed Windows + WSL2 local development is the environment Codex needs to remain stable in.

A potentially relevant report is #24268, where Windows Desktop with WSL-backed sessions repeatedly produced an invalid mixed C:\mnt\c\... path during Chrome plugin reconciliation. I am not claiming the same root cause, but the Windows/WSL path and Chrome-plugin interaction makes it relevant to investigate.

What issue are you seeing?

During extended local development work in Codex Desktop (ChatGPT Work), the application progressively consumes enough resources that the entire Windows system becomes severely sluggish.

Observed behavior:

  • Performance degrades over time while doing local Codex work.
  • Multiple ChatGPT/Codex processes appear to remain active or accumulate.
  • Browser-driven web development tasks also appear to leave many Chrome windows/tabs open after the work has finished. After repeated tasks, dozens of tabs may remain open.
  • Eventually the slowdown affects the whole desktop, not only Codex: even mouse movement becomes visibly laggy.
  • Closing the current task is not enough to restore normal performance.
  • The reliable recovery is either:
  • reboot Windows, or
  • exit Codex/ChatGPT and manually terminate all remaining ChatGPT-related processes in Task Manager.
  • Because this occurs repeatedly, local Codex usage becomes difficult to rely on.

I suspect unreleased processes, browser sessions/tabs, memory, or temporary state may be accumulating, but I have not yet isolated which resource is the primary cause. This report intentionally distinguishes that hypothesis from the directly observed symptoms.

What steps can reproduce the bug?

  1. Open Codex Desktop on Windows.
  2. Work across one or more of the normal workspace layouts above: native Windows NTFS, Windows NTFS accessed through WSL2 /mnt/c, or the WSL2 Linux filesystem.
  3. Perform local development work for an extended period.
  4. Include web-development/browser-control tasks that open Chrome pages.
  5. Finish or switch between multiple tasks over time.
  6. Observe that Chrome windows/tabs and ChatGPT/Codex-related processes do not appear to be fully cleaned up.
  7. Continue working until overall Windows responsiveness degrades.
  8. Observe severe system-wide lag, including laggy mouse movement.
  9. Quit the visible app or close tasks; the slowdown may persist.
  10. Reboot Windows, or terminate every ChatGPT-related process in Task Manager; performance returns to normal.

The issue is progressive and may require a long session or repeated local/browser tasks rather than a small one-shot reproduction.

What is the expected behavior?

  • Codex should clean up local worker/helper processes when work completes or is cancelled.
  • Browser automation should close or reuse browser pages it opened, and should not leave dozens of Chrome tabs/windows behind after tasks finish.
  • Memory, temporary state, process count, handles, and browser sessions should remain bounded during long-running local work.
  • Quitting Codex/ChatGPT should terminate all owned background processes cleanly.
  • Extended local work should not make the whole Windows desktop unresponsive.
  • Codex Desktop should remain stable when projects are stored on native Windows NTFS, accessed from WSL2 through /mnt/c, or stored in the WSL2 Linux filesystem and exposed through \\wsl.localhost.
  • Cross-environment path translation, file watching, worker cleanup, and browser/plugin cleanup should remain correct and bounded.

Additional information

Possibly related:

  • #25390 — Windows Desktop becomes extremely sluggish with large local threads. My symptoms are similar, but the degradation is system-wide and also appears correlated with accumulated ChatGPT/Codex processes and many leftover Chrome tabs after web-development tasks.
  • #34260 — Windows cleanup/process accumulation causing system-wide sluggishness.
  • #12491 — child processes not reaped after task completion (reported on macOS, but similar lifecycle concerns).
  • #24268 — Windows+WSL path translation produced invalid mixed paths during Chrome plugin reconciliation.

Useful diagnostics I can collect on the next occurrence if maintainers recommend a preferred method:

  • Codex Desktop version and Windows build
  • Task Manager process counts and memory usage before/after cleanup
  • Chrome process/tab counts
  • Codex logs
  • temp/state directory growth
  • a process tree or Process Explorer capture

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 10 days ago

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

  • #38784
  • #38825
  • #38981
  • #38751

Powered by Codex Action

wonkwonlee · 10 days ago

I reviewed the suggested duplicates.

There is substantial overlap, but I do not yet have enough diagnostics to identify this report as one exact duplicate:

  • #38825 is the closest match for the accumulated ChatGPT/Codex-related process population and system-wide Windows slowdown. That report specifically measured explosive duplication of Node/MCP process stacks.
  • #38751 is the closest match for retained/restored Browser tabs and associated renderer/memory growth. I still need to distinguish whether the dozens of tabs in my reproduction are persisted Codex in-app Browser pages, externally controlled Chrome tabs, or both.
  • #38981 is related to retained per-thread STDIO MCP runtimes, but its local-proxy and CLOSE_WAIT socket condition has not been established in my environment.
  • #38784 covered a similar combination of task-runtime and Browser retention, but it has already been closed as an umbrella duplicate with its evidence split across narrower issues.

A potentially distinguishing reproduction condition in my case is that this happens during my normal mixed Windows + WSL2 development workflow across all three storage/access patterns:

  • native Windows NTFS workspaces, e.g. C:\Users\wonkw\Obsidian\GotSaeng-OS
  • Windows NTFS accessed from WSL2 through /mnt/c/Users/.../Documents/project
  • WSL2 Linux filesystem projects, exposed to Windows as \\wsl.localhost\Ubuntu\home\devtranger\projects

Because I have not yet captured process-family counts, Browser ownership, or app version during an affected episode, closing this as a specific duplicate now could incorrectly merge multiple symptoms. On the next occurrence I will try to capture:

  • Codex Desktop version and Windows build
  • counts and memory for ChatGPT/Codex, node.exe, MCP, Chrome/Browser renderer, VmmemWSL, taskkill.exe, conhost.exe, and WmiPrvSE.exe
  • whether the retained tabs are in-app Browser tabs or external Chrome tabs
  • which of the three workspace layouts was active
  • whether fully quitting Codex, closing Chrome, or wsl --shutdown independently restores responsiveness

If those measurements match #38825 or #38751 cleanly, I will move the reproduction evidence to the matching issue and close this one as a duplicate.