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

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
2. The same kind of Windows/NTFS workspace accessed from WSL2 through /mnt/c
   • Pattern: /mnt/c/Users/.../Documents/project
3. 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

Begin by reproducing a long Windows session across the listed NTFS and WSL2 workspace layouts while recording Task Manager process and memory counts, Chrome tab counts, Codex logs, temp/state growth, and a process tree. Compare behavior before and after quitting Codex or terminating remaining ChatGPT-related processes; done means owned processes, browser tabs, memory, handles, and temporary state remain bounded while the desktop stays responsive.