Windows app local thread can hang Explorer/taskbar and Microsoft IME

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

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

26.623.19656.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 Windows 25H2, build 26200.8737

What issue are you seeing?

The Codex Windows app appears to trigger Windows Shell instability when using a local Windows-native thread.

Symptoms:

  • explorer.exe / taskbar hangs or restarts
  • taskbar disappears or becomes unusable
  • Microsoft IME candidate window disappears
  • typing/input UI becomes broken until Explorer/TextInputHost/ctfmon are restarted or the user logs out/reboots
  • this happened more often with multiple local threads/worktrees, but later reproduced after reboot with only a single local Codex thread running

Observed related components:

  • explorer.exe
  • StartMenuExperienceHost
  • ShellExperienceHost
  • TextInputHost
  • ctfmon

Windows Error Reporting showed repeated explorer.exe AppHangB1 / AppHangXProcB1 events. Codex also had MoAppHang events.

What steps can reproduce the bug?

  1. Reboot Windows and sign in.
  2. Launch Codex Windows app.
  3. Open a local Windows-native project/workspace.
  4. Start a local Codex thread using PowerShell / Windows-native agent.
  5. Let Codex inspect system/application logs or run local commands.
  6. Observe that Windows taskbar / Explorer hangs or restarts, and Microsoft IME candidate UI disappears.

This originally happened more often when running multiple Codex local threads/worktrees in parallel. However, after reboot it also happened with only one local Codex thread active.

Session id: not available yet / will provide if collected through Codex feedback.
Token usage/context window usage: N/A.

What is the expected behavior?

Codex local threads should not destabilize Windows Shell components.

Expected:

  • taskbar remains responsive
  • explorer.exe does not hang/restart
  • Microsoft IME candidate window remains visible
  • TextInputHost / ctfmon continue working
  • local Codex commands may be slow or fail, but should not break the Windows desktop shell

Additional information

Environment:

  • Codex Windows app: 26.623.19656.0
  • Windows: 25H2, build 26200.8737
  • Platform command output: Microsoft Windows NT 10.0.26200.0 x64
  • Local workspace path included spaces: D:\Codex AI\Wenqi
  • CODEX_HOME: D:\CodexHome
  • Shell: PowerShell
  • Local agent mode: Windows native

Observed event/report details:

  • explorer.exe AppHangB1 / AppHangXProcB1 repeated on 2026-07-07
  • related AppHangXProcB1 entries referenced svchost.exe:umpo
  • Codex MoAppHang report observed
  • one Codex report ID: 657610c3-b743-4a09-a755-6180b5305ff9
  • one explorer report ID: 48c5aeb0-f768-45e2-9edb-7b935a8c2c8f

Temporary recovery:
Restarting explorer.exe, ctfmon.exe, and TextInputHost sometimes restores the taskbar and IME. Logging out or rebooting is more reliable.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31236

Powered by Codex Action

Menvradev · 1 month ago

Same Codex version here: 26.623.19656.0 on Windows 11.

My case is slightly different from the original report:

  • Codex UI freezes after I start typing a prompt.
  • The app window becomes completely unresponsive.
  • DevTools cannot be opened with Ctrl+Shift+I once frozen.
  • Backend seems alive; Codex process still uses CPU.
  • Explorer/taskbar did not visibly crash in my case.
  • Docker Desktop + WSL2 are installed.
  • WSL detection in logs shows Ubuntu and docker-desktop, both stopped.
  • Deleting auth.json temporarily helped, but the freeze came back shortly after.

Attached logs from the affected sessions.