›_ Codex Issues
Codex Issues / #31236

Windows Codex app freezes taskbar / Alt+Tab / Explorer when repeatedly spawning PowerShell and querying Shell icons

Open 💬 6 comments Opened Jul 6, 2026 by TakakoTeio

Summary

On Windows, the Codex app can freeze the Windows Shell while running small local tasks. When the issue occurs, the taskbar, Start menu, and Alt+Tab stop responding, while already-open applications remain clickable and usable. Closing Codex or killing PowerShell immediately restores the Shell.

The issue appears related to Codex repeatedly spawning Windows PowerShell 5.1 and running a Shell icon extraction script that calls Windows Shell APIs through shell32.dll.

Environment

  • OS: Windows
  • Product: Codex Windows app
  • Shell affected: Explorer / taskbar / Start menu / Alt+Tab
  • Child processes observed while Codex is running:
  • powershell.exe
  • pwsh.exe
  • git.exe
  • npm / node.exe
  • python.exe

Symptoms

When Codex is open and performing even small tasks, especially tasks involving PowerShell document reads or command execution:

  • Windows taskbar becomes completely unresponsive.
  • Start menu becomes unresponsive.
  • Alt+Tab becomes unresponsive.
  • Already-open applications remain clickable and usable.
  • Closing Codex immediately restores the Shell.
  • Killing powershell.exe / pwsh.exe also restores the Shell.

This happens even with small-scale Codex tasks. It is not limited to large projects.

Reproduction steps

  1. Open the Codex Windows app.
  2. Ask Codex to perform a small local task that causes it to read documents or execute commands through PowerShell.
  3. Wait until Codex starts spawning PowerShell child processes.
  4. The Windows taskbar, Start menu, and Alt+Tab become unresponsive.
  5. Run:
taskkill /IM powershell.exe /F
  1. The taskbar / Alt+Tab / Shell immediately recover.

If needed, also run:

taskkill /IM pwsh.exe /F

Observed behavior

  • Explorer / Shell hangs.
  • Windows taskbar, Start menu, and Alt+Tab stop responding.
  • Already-open application windows are still interactive.
  • Killing PowerShell restores the Shell.
  • Closing Codex restores the Shell.

Expected behavior

Codex should not freeze Explorer, the taskbar, the Start menu, or Alt+Tab while spawning PowerShell child processes or extracting app icons.

Evidence collected

1. WER reports

WER reports show repeated explorer.exe AppHangB1 and Codex MoAppHang around the same time.

The relevant WER archive was collected into:

wer_taskbar_codex_safe_20260706_170433 (2).zip

The WER reports do not include full memory dumps in this safe archive.

2. PowerShell Operational logs

PowerShell Operational logs show repeated Windows PowerShell startup events:

  • Event ID 40961: PowerShell console starting
  • Event ID 40962: PowerShell console ready for user input
  • Event ID 53504: Windows PowerShell AppDomain startup

In one collected window, the full PowerShell log showed hundreds of Windows PowerShell 5.1 process/AppDomain startups within about 30 minutes.

The full PowerShell evidence is in:

powershell_full_20260706_174915.zip
powershell_operational_last20min.txt

3. Codex-related ScriptBlock

The full PowerShell logs include Codex-related ScriptBlocks defining:

CodexShellIconNative

The script appears to:

  • Use Add-Type
  • Load System.Drawing
  • Call shell32.dll
  • Use SHCreateItemFromParsingName("shell:AppsFolder\" + appId)
  • Use IShellItemImageFactory.GetImage(...)
  • Read from CODEX_NATIVE_DESKTOP_APP_ICON_PATH
  • Convert an app icon to a base64 data URL

This suggests Codex is repeatedly touching Windows Shell / AppX icon infrastructure from PowerShell child processes.

Suspected cause

The Codex Windows client appears to repeatedly spawn Windows PowerShell 5.1 and synchronously query Windows Shell / AppX icon infrastructure via shell32.dll and shell:AppsFolder.

This may block or deadlock Explorer / Shell, causing the taskbar, Start menu, and Alt+Tab to stop responding.

Suspected chain:

Codex Windows app
  -> repeatedly starts powershell.exe
  -> runs CodexShellIconNative / Shell icon extraction ScriptBlock
  -> calls shell32.dll / shell:AppsFolder / IShellItemImageFactory
  -> Explorer / Windows Shell becomes blocked
  -> taskbar, Start menu, Alt+Tab freeze
  -> killing powershell.exe immediately restores Shell

Workarounds tested

  • Exiting TranslucentTB did not resolve the issue.
  • Killing powershell.exe restores the Shell.
  • Closing Codex restores the Shell.
  • Logs did not support DWM, GPU, disk, or NTFS as the primary cause.
  • The issue still happens on small Codex tasks, so task size alone is not the explanation.

Attachments included

I am attaching the following files to this issue:

wer_taskbar_codex_safe_20260706_170433 (2).zip
powershell_full_20260706_174915.zip
powershell_operational_last20min.txt

I am not attaching memory.hdmp unless maintainers explicitly request it, because it may contain sensitive memory contents.

Request

Please investigate whether the Windows Codex app is spawning too many PowerShell processes and whether the CodexShellIconNative / shell32.dll / shell:AppsFolder icon extraction path can block Explorer or the Windows Shell.

It may help to:

  • Avoid invoking Windows PowerShell for icon extraction.
  • Cache the app icon instead of querying Shell repeatedly.
  • Avoid synchronous Shell COM calls from repeated child PowerShell processes.
  • Rate-limit or deduplicate PowerShell process creation.
  • Move icon extraction out of the Shell-critical path.

wer_taskbar_codex_safe_20260706_170433 (2).zip
powershell_full_20260706_174915.zip
powershell_operational_last20min.txt

View original on GitHub ↗

6 Comments

ACEMILIO · 13 days ago

I can reproduce what looks like the same issue.

Additional symptoms on my machine:

  • taskbar / Explorer becomes unstable
  • Microsoft IME candidate window disappears
  • TextInputHost / ctfmon appear affected
  • this reproduced even after reboot with only one local Codex thread active, not only with multiple parallel threads/worktrees

Environment:

  • Codex Windows app: 26.623.19656.0
  • Windows: 25H2 build 26200.8737
  • Local agent: Windows native / PowerShell
  • CODEX_HOME: D:\CodexHome

I also opened a related issue: #31444

This looks consistent with the PowerShell / Shell icon extraction path described here. In my case, restarting explorer.exe / ctfmon / TextInputHost temporarily restores the desktop shell and IME.

pupper9 · 13 days ago

I can reproduce this issue on command.

  • Start Codex
  • Press Win + Shift + S to open the snipping tool.
  • Select any area using the snipping tool.
  • Start button and windows + hotkeys immediately become unresponsive.
  • Close codex
  • Start button and windows key immediately work again.
ACEMILIO · 12 days ago

I tested running both the Codex app and the project entirely within WSL. In that setup, I’m no longer able to reproduce the File Explorer crash or unresponsiveness.
This suggests the issue may be related to the Windows-side filesystem integration, process interaction, or how Codex accesses the project when it is located outside WSL, rather than the project itself.

Onlydreams · 11 days ago

I have another reproduction that looks like the same failure family, with an additional display-composition symptom.

Environment, sanitized:

  • Codex Windows app: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0
  • Windows: 25H2, build 26200.8737, x64
  • Local agent: Windows native / PowerShell
  • Display/GPU: desktop Windows machine with a high-refresh external monitor and NVIDIA GPU

What happened:

  • At about 2026-07-09 17:43 local time, while Codex was open and a browser-related surface was active, the display partially failed to repaint.
  • The left side of the screen kept a stale browser/desktop frame, while the rest of the monitor became a large dark/gray/black region.
  • Input/shell responsiveness was impaired during the incident, then recovered.
  • I am not attaching the photo publicly because it contains private desktop/environment details, but the visual symptom was a partial black/stale-frame desktop, not just taskbar or Start menu lag.

Evidence collected immediately afterward:

  • No Display 4101, LiveKernelEvent 141/117, WHEA, DWM crash, or LiveKernelReports dump was recorded for the incident window.
  • Application log only had a nearby Chromium/Edge informational entry; no Chrome/Codex/DWM crash report was present.
  • PowerShell Operational logs showed a large burst in the same time window:
17:38     6
17:39     6
17:40     6
17:41     6
17:42    86
17:43   126
17:44    36
17:45   141
17:46    33
17:47    42
17:48   107

Event-id breakdown for 17:38-17:49:

40961   175   PowerShell console starting
40962   175   PowerShell console ready
53504   175   PowerShell AppDomain / IPC listener startup
4100     61   warnings
4103      6
4104      3

The ScriptBlock content in that window included the Codex icon extraction path already mentioned in this issue, including CodexShellIconNative, shell32.dll, IShellItemImageFactory, shell:AppsFolder, and CODEX_NATIVE_DESKTOP_APP_ICON_PATH.

So in this repro, the strongest correlation is:

Codex open / browser-related surface active
  -> burst of PowerShell process startups
  -> CodexShellIconNative / shell32.dll / shell:AppsFolder icon extraction appears in PowerShell logs
  -> Windows shell/input responsiveness degrades
  -> desktop composition partially fails to repaint, leaving stale-frame + black/gray screen regions

This may be the same underlying Shell API / PowerShell spawning issue, but with the visible symptom extending into DWM/desktop composition rather than only Start/taskbar/Alt+Tab.

Onlydreams · 11 days ago

Small visual-detail follow-up to my previous comment: the captured display artifact also included a thin horizontal multicolor corruption line near the boundary of the stale browser surface and the black/gray region.

So the visible symptom was not only a stale frame plus black area; there was also a narrow horizontal artifact/corruption strip at the edge of the browser/composition surface. That makes it look like the shell/input freeze can coincide with desktop-composition or GPU-surface corruption, even though Windows did not record a Display 4101 / LiveKernelEvent / DWM crash for that window.

I am still not attaching the photo publicly because it contains private desktop details.

GiftedMamba · 3 days ago

I can reproduce what appears to be the same issue.

Additional observations:

Codex CLI and the Rider integration work normally; the issue appears specific to the Windows desktop app.
Disabling Codex task-completion notifications significantly reduced the frequency of the freezes, although they still occur occasionally.
On one occasion, Codex worked normally throughout the day, but the freeze occurred shortly after I opened ChatGPT alongside it.
When it happens, Explorer becomes unresponsive and starting new processes may stop working. Killing the Codex process immediately restores the system.

The notification-related behavior may be relevant to the suspected Windows Shell/icon integration path.