Skip to content

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

Open
Open
Windows Codex desktop app spawns hundreds of taskkill.exe and conhost.exe during local tool execution#33778
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancetool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

Description

@WangZhehao37
WangZhehao37
opened on Jul 17, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    tool-callsIssues related to tool calling
    performance
    on Jul 17, 2026

  2. github-actions commented on Jul 17, 2026

    @github-actions
    github-actionsbot
    on Jul 17, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. a1014702011 commented on Jul 17, 2026

    @a1014702011
    a1014702011
    on Jul 17, 2026

    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.

  4. Paliverse commented on Jul 18, 2026

    @Paliverse
    Paliverse
    on Jul 18, 2026

    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.

  5. eva763057345-lab commented on Jul 18, 2026

    @eva763057345-lab
    eva763057345-lab
    on Jul 18, 2026 – with ChatGPT Codex Connector

    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.

  6. HDDen commented on Jul 19, 2026

    @HDDen
    HDDen
    on Jul 19, 2026

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

  7. athan614 commented on Jul 20, 2026

    @athan614
    athan614
    on Jul 20, 2026

    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.

  8. suiyuebaobao commented on Jul 22, 2026

    @suiyuebaobao
    suiyuebaobao
    on Jul 22, 2026 – with ChatGPT Codex Connector

    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:

    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.

  9. zhuangbowu commented on Jul 23, 2026

    @zhuangbowu
    zhuangbowu
    on Jul 23, 2026

    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.

  10. zhuangbowu commented on Jul 27, 2026

    @zhuangbowu
    zhuangbowu
    on Jul 27, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancetool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions