Built-in Agent subsystem enters a runaway loop, repeatedly running taskkill and launching conhost.exe, maxing out the CPU

English translation:

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

26.715.4045.0

What subscription do you have?

plus

What platform is your computer?

Windows 11

What issue are you seeing?

The built-in Agent subsystem entered a runaway loop, repeatedly running taskkill (possibly for process cleanup) and launching conhost.exe (creating a new conhost for every command execution), causing CPU usage to max out.
1..30 | ForEach-Object {

> $tk = @(Get-Process taskkill -ErrorAction SilentlyContinue).Count > $ch = @(Get-Process conhost -ErrorAction SilentlyContinue).Count > $ps = @(Get-Process powershell -ErrorAction SilentlyContinue).Count > > "{0:HH:mm:ss} taskkill={1} conhost={2} powershell={3}" -f ` > (Get-Date),$tk,$ch,$ps > > Start-Sleep 1 > }

18:53:55 taskkill=174 conhost=188 powershell=1
18:53:56 taskkill=184 conhost=199 powershell=1
18:53:57 taskkill=196 conhost=212 powershell=1
18:53:58 taskkill=209 conhost=224 powershell=1
18:53:59 taskkill=221 conhost=238 powershell=3
18:54:00 taskkill=231 conhost=248 powershell=3
18:54:01 taskkill=242 conhost=258 powershell=3
18:54:02 taskkill=251 conhost=267 powershell=3
18:54:03 taskkill=261 conhost=278 powershell=3
18:54:04 taskkill=271 conhost=288 powershell=3
18:54:05 taskkill=282 conhost=300 powershell=3
18:54:06 taskkill=293 conhost=310 powershell=3
18:54:07 taskkill=306 conhost=322 powershell=3
18:54:09 taskkill=303 conhost=316 powershell=3
18:54:10 taskkill=303 conhost=315 powershell=4
18:54:11 taskkill=302 conhost=313 powershell=4
18:54:12 taskkill=293 conhost=303 powershell=3
18:54:13 taskkill=285 conhost=296 powershell=3
18:54:14 taskkill=292 conhost=303 powershell=3
18:54:15 taskkill=298 conhost=308 powershell=3
18:54:16 taskkill=300 conhost=309 powershell=3
18:54:17 taskkill=302 conhost=313 powershell=3
18:54:18 taskkill=299 conhost=306 powershell=1
18:54:19 taskkill=302 conhost=310 powershell=1
18:54:20 taskkill=298 conhost=308 powershell=3
18:54:21 taskkill=293 conhost=301 powershell=2
18:54:22 taskkill=296 conhost=304 powershell=1
18:54:23 taskkill=295 conhost=303 powershell=1
18:54:25 taskkill=295 conhost=303 powershell=1
18:54:26 taskkill=296 conhost=304 powershell=1
<html>
<body>
<!--StartFragment-->
Process | Behavior
-- | --
ChatGPT.exe (64856) | Parent process, spawns a large number of taskkill.exe processes
codex.exe (42884) | Parent process, spawns a large number of conhost.exe processes
taskkill / conhost | Repeatedly executed by Codex

<!--EndFragment-->
</body>
</html>

What steps can reproduce the bug?

It is triggered as soon as Codex is launched.

What is the expected behavior?

Fix the bug that causes CPU usage to max out.

Additional information

_No response_

<!-- codex-issue-translator -->

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

• #33778
• #33776

Powered by Codex Action

Additional same-build reproduction with a startup-resume A/B test.

Environment

• Desktop package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
• Desktop app-server reported in logs: 0.145.0-alpha.18
• Windows NT 10.0.26200.8655, x64

Process/WMI evidence

The issue was first noticed as WMI Provider Host using 58.4% total CPU (about 231 MB working set). Process-parent tracing attributed the repeated cleanup activity to the Codex desktop ChatGPT.exe process, not to the other development tool that happened to be open.

A 12-second high-frequency sample captured 126 newly created processes:

• 37 taskkill.exe
• 30 git.exe
• 7 bash.exe
• 51 conhost.exe

A later 9-second window captured 98 taskkill.exe invocations. WMI Activity Event 5858 repeatedly showed cancelled Win32_Process queries from short-lived client PIDs with 0x80041032 (WBEM_E_CALL_CANCELLED). The local logs_2.sqlite grew to about 422 MB while the loop was active.

Reinstalling the same MSIX build did not help because the local Codex state survived.

Archive/resume A/B test

The most useful new finding is that this appears tied to stale resumable execution state:

1. With Codex fully closed, I backed up the local state and marked all eight implicated parent/subagent thread records archived.
2. After relaunch, those archive flags were verified to still be set.
3. Nevertheless, after a 150-second startup/recovery window, another 45-second sample captured 122 taskkill.exe invocations. Existing bash, git, and a prior project launch command were being revived even though no corresponding task was visibly active.
4. I then closed Codex and reversibly moved the local session/rollout directories plus the related state/log databases, session index, and global thread state out of ~/.codex, while retaining authentication and configuration.
5. After relaunch and the same 45-second measurement, the result was 0 taskkill.exe invocations and 0 new WMI errors. The desktop app remained stable.

Because the quarantine moved several state surfaces together, this does not prove that one specific file under sessions/ is solely responsible. It does strongly implicate startup resume/reconciliation of retained local thread/rollout state. Restoring the affected state has not been attempted because it may retrigger the storm.

Expected behavior

• An archived task must not automatically resume tool execution.
• Startup recovery must not replay stale shell work without visible task state and user control.
• Recovery failures need bounded retries/backoff instead of a rapid spawn/kill loop.
• Any task executing project commands should be visible in the UI.

This also appears related to #34025, #33776, #23851, and #22411. I retained the quarantined evidence and can provide sanitized process samples or WMI entries if maintainers request them.

Subscription and weekly-quota impact

• Subscription: ChatGPT Pro (20x)
• Local token_count.rate_limits telemetry confirms plan_type=pro and a 10080-minute (7-day) usage window.
• For the same weekly window/reset, usage was 34% at 2026-07-18 21:38 Sydney time and reached 90% at 2026-07-19 13:43 during the runaway resume incident: an increase of 56 percentage points in about 16 hours.
• The latest reading after containment/reporting is 91% used, leaving only 9% of the weekly allowance. The reset is scheduled for 2026-07-25 13:25 Sydney time.
• I did not intentionally start workload proportional to this increase. The rise coincided with hidden resumed parent/subagent executions and the process storm described above.

The timing strongly associates the quota consumption with the runaway recovery behavior, but exact billing attribution requires a server-side audit. Please audit usage for this incident window and consider restoring weekly quota consumed by product-driven background execution.

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 runaway taskkill/conhost.exe loop 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.