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

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

• #33776

Powered by Codex Action

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.

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.

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.

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

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.

The taskkill.exe/conhost.exe storm during local tool execution here is very close to the downstream behavior I measured. In my reproduction, repeated desktop Git refreshes were upstream, so this workaround is worth testing if the same parent chain is present.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

• Repository: https://github.com/suiyuebaobao/codex-git-refresh-workaround
• Direct download: https://raw.githubusercontent.com/suiyuebaobao/codex-git-refresh-workaround/main/Codex-Git-Disabled.cmd

It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

Usage: fully exit Codex from the Windows system tray, then run the script.

This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. If the process storm in this issue has a different upstream cause, this may not apply. The launcher does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.

I can reproduce this issue on:

• Codex App / ChatGPT Desktop: 26.715.72359
• Release date: July 22, 2026
• OS: Windows 11 x64
• Subscription: ChatGPT Plus

I found a more specific and reliable trigger:

1. Open project A.
2. Click "New task".
3. While the new task is still initializing, switch to project B.
4. A large number of taskkill.exe processes begin to appear.
5. Repeating the project switch causes more processes to accumulate.

Remaining inside the same project generally does not trigger the issue.
It is especially easy to reproduce by clicking "New task" and then
switching projects before initialization finishes.

Observed behavior:

• Overall CPU usage reached approximately 60%.
• A Node.js runtime used approximately 1.5 GB of memory.
• Windows Management Instrumentation showed elevated CPU usage.
• Security software CPU usage also increased because of the large number

of rapidly created processes.

• The system became noticeably slower.

After completely exiting Codex:

• New taskkill.exe processes stopped being created.
• Existing taskkill.exe processes disappeared after approximately

one to two minutes.

• CPU usage remained elevated temporarily while WMI and the remaining

processes were clearing.

Expected behavior:

Switching projects should cancel and clean up the previous task
initialization only once. Codex should not repeatedly spawn large
numbers of taskkill.exe processes or leave Node.js runtimes and cleanup
processes behind.

Update: this issue appears resolved on my machine after updating to Codex App / ChatGPT Desktop version 26.721.41059 (released July 25, 2026).

I retested the previously reliable trigger:

1. Open project A.
2. Click New task.
3. Switch to project B while the task is initializing.
4. Repeat the project switch several times.

After the update, I no longer see the previous taskkill.exe process storm, and the system no longer becomes sluggish or unresponsive. CPU and memory usage also remain normal during this workflow.

For my environment, version 26.721.41059 appears to have fixed the problem. Other users may still need to verify on their own systems.