›_ Codex Issues
Codex Issues / #33778

Windows Codex desktop app spawns hundreds of taskkill.exe and conhost.exe during local tool execution

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

Environment

  • Windows build: 10.0.26200.8875
  • Codex desktop app package: OpenAI.Codex_26.715.2305.0_x64
  • Local Codex task using shell/tool calls. Multiple plugins/MCP integrations may be installed.

Observed behavior

During a local Codex desktop session, the ChatGPT/Codex renderer repeatedly spawned a large number of taskkill.exe processes, each with a paired conhost.exe process.

A process snapshot showed:

  • 178 C:\Windows\System32\taskkill.exe processes, totaling about 506 MB private memory
  • 197 C:\Windows\System32\conhost.exe processes, totaling about 326 MB private memory
  • The taskkill.exe processes were created in a tight 10-second window
  • Inspecting one live taskkill.exe showed its parent process was ChatGPT.exe (a Codex desktop renderer process)
  • The counts persisted rather than promptly returning to a bounded baseline

This contributes substantial memory pressure and makes the process list difficult to inspect. The system has 16 GB RAM and only about 1.7 GB was available during the investigation.

Expected behavior

Command-cleanup helpers and their console hosts should exit promptly after a tool invocation. The number of taskkill.exe / conhost.exe children under the desktop app should remain bounded.

Notes

  • This may be related to the existing Codex desktop/MCP child-process lifecycle reports, but the observable Windows symptom here is specifically a large, persistent ChatGPT.exe -> taskkill.exe -> conhost.exe process tree.
  • I did not confirm a GPU-memory leak: total shared GPU usage was about 0.67 GB at the snapshot, which does not explain the overall RAM pressure.
  • Restarting the desktop app is currently the only reliable cleanup observed.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 days ago

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

  • #33776

Powered by Codex Action

a1014702011 · 3 days ago

I can reproduce a very similar issue on Codex Desktop for Windows.

Environment:

  • Codex desktop package: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
  • Hardware: Dell G16 7630, Intel i7-13650HX, 32 GB RAM
  • Workspace: local project workspace

Impact:

  • Entering a specific Codex conversation/session makes Windows input nearly unusable.
  • Mouse movement floats/stutters.
  • Keyboard input becomes unresponsive or severely delayed.
  • Killing the offending ChatGPT.exe process immediately restores system responsiveness.

Process evidence:
A ChatGPT.exe process repeatedly spawned large numbers of taskkill.exe children with commands like:

C:\Windows\System32\taskkill.exe /pid <pid> /t /f

Observed parent processes in separate reproductions:

  • ChatGPT.exe PID 50164
  • ChatGPT.exe PID 23596

Executable path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

Diagnostic command used:

Get-CimInstance Win32_Process -Filter "name='taskkill.exe'" |
  Select-Object ProcessId,ParentProcessId,CommandLine,CreationDate

Result:
All observed taskkill.exe processes had ParentProcessId pointing to ChatGPT.exe.

This appears to be per-conversation/session state: unloaded conversations do not consume resources, but entering the affected conversation can retrigger the ChatGPT.exe -> taskkill.exe loop.

Paliverse · 3 days ago

Can confirmed with two concurrent ultra sessions, taskkill was reaching nearly 1,500 separate processes. It was Wild! Sadly have to use the CLI for now until this is fixed.

eva763057345-lab · 2 days ago

I can still reproduce this after the Microsoft Store app updated to Codex Desktop 26.715.3651.0.

New reproduction evidence

  • Windows x64 system with 15.89 GB RAM.
  • Performed a full Windows restart before retesting.
  • Launched Codex from the standard official AppX/Start menu entry.
  • The main ChatGPT.exe process was parented by explorer.exe and its command line contained no custom launcher or --proxy-server argument.
  • The AppX package reported status Ok.
  • Rotating the dedicated Codex log database and rebuildable application caches, while preserving sessions and sign-in state, did not prevent recurrence.

After local shell/tool execution, one live snapshot showed:

| Measurement | Value |
| --- | ---: |
| Total processes | 362 |
| taskkill.exe | 21 |
| conhost.exe | 68 |
| ChatGPT.exe working set / private memory | 1780.1 MB / 1589.7 MB |
| codex.exe working set / private memory | 348.0 MB / 272.3 MB |
| System memory used / free | 70.2% / 4.73 GB |

Parent breakdown for the 21 live taskkill.exe processes:

  • 16 were direct children of the main ChatGPT.exe process.
  • 3 were children of codex.exe.
  • 2 were children of other taskkill.exe processes.

A separate six-second stability sample after the earlier clean restart showed active growth:

| Measurement | Start | Six seconds later |
| --- | ---: | ---: |
| Total processes | 323 | 381 |
| taskkill.exe | 3 | 36 |
| conhost.exe | 14 | 44 |

The number of ChatGPT.exe and codex.exe processes stayed constant during that sample, while the cleanup/console processes increased.

There were no matching Windows Application Error or Hang events (Event IDs 1000/1002) during the latest two-hour observation window, so this recurrence presented as a process-cleanup/performance failure rather than a new crash.

Once the system was affected, a later local shell invocation failed immediately with process exit code -1073741502. I am treating that as a possible secondary symptom rather than the root cause.

Conclusion

The problem remains reproducible in 26.715.3651.0 after a full reboot and through the ordinary official AppX entry. This also rules out the machine's optional custom proxy launcher as a necessary trigger. The strongest observable trigger remains local tool/shell execution inside Codex Desktop.

No conversation data, usernames, repository names, raw databases, or complete logs are attached. I can provide additional sanitized counters if maintainers request them.

HDDen · 1 day ago

Confirmed, is only way to make my computer responsive again is suspending chatgpt.exe via process explorer.

athan614 · 7 hours ago

Same issue here, ChatGPT/Codex windows app is stuck in a runaway process-enumeration loop with taskkill.exe whenever launched, causing WMI to get stuck at 25% CPU constantly, lagging my entire PC.