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

Open 💬 2 comments Opened Jul 7, 2026 by ACEMILIO

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 ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗