›_ Codex Issues
Codex Issues / #40772

[Windows][Codex App] Main HWND becomes unclickable because it is left Enabled=False with no active popup

Open 💬 0 comments Opened Aug 26, 2026 by ArgaAAL

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

26.818.61809

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Windows Codex/ChatGPT desktop app intermittently becomes completely non-interactive to pointer input, even though the app is still alive, visibly responsive, and continuing its work. There is no visible error message.

This is not a conventional crash or rendering freeze.

While the problem is occurring, all of the following continue to work:

  • An active Codex agent run continues executing.
  • New progress, text, animations, and status changes continue rendering.
  • Mouse-wheel and touchpad scrolling continue working.
  • Keyboard focus navigation with Tab works.
  • Keyboard window operations such as F11, Win+Arrow, minimize, restore, and snap work.
  • Other applications remain fully responsive.
  • The same mouse and touchpad work normally outside Codex.

However, all pointer interaction within the affected Codex window stops working:

  • Buttons do not respond to hover.
  • Left-clicks do nothing.
  • The composer and app controls cannot be clicked.
  • Command-palette or overlay controls are also unclickable.
  • Native title-bar buttons such as minimize, maximize, and close do not react to hover or clicks.
  • Both an external mouse and the built-in touchpad produce the same result.

Win32 inspection identified the actual failure state. The affected top-level window was still visible but had been disabled at the operating-system level:

App              PID   HWND        Enabled  Visible  LastPopup   EnabledPopup
ChatGPT          6504  0x803C2     False    True     0x803C2     0x0
ChatGPT (Beta)  17340  0x1AA0BAC   True     True     0x1AA0BAC   0x0

The PID and HWND values are ephemeral, but the important state is:

Visible      = True
Enabled      = False
LastPopup    = the main window itself
EnabledPopup = 0

There was no remaining enabled popup or modal for the user to close or activate.

A separate GUI-thread diagnostic also showed:

GUI_OK  = True
Capture = 0x0
MoveSize = 0x0

Therefore, the window was not stuck in a Win32 mouse-capture, drag, or resize operation.

Calling:

EnableWindow(mainHwnd, TRUE)

immediately restored all mouse and touchpad interaction in the existing window.

The app did not need to be restarted, the Codex app-server remained alive, and the existing conversation/run state was preserved.

This has occurred repeatedly on separate days, and I have observed the same symptom in both the Stable and Beta Windows desktop apps.

The initiating action is still unknown. The observed failure state is consistent with a native modal/dialog lifecycle path leaving the main Codex owner HWND disabled after no enabled popup remains. The initiating dialog or action has not yet been identified.

This appears potentially related to #35866, which reports the same Enabled=False / LastActivePopup=self / EnabledPopup=0 state in the Codex VS Code extension, but this report is specifically for the standalone Windows Codex desktop app.

What steps can reproduce the bug?

The trigger is currently intermittent; I have not yet isolated a deterministic action that causes the window to enter this state.

Observed reproduction:

  1. Launch the Codex Windows desktop app and use it normally, including running Codex tasks.
  2. After some period of use, the main Codex window intermittently becomes completely unclickable.
  3. When this happens:
  • the active Codex task continues running;
  • new text/progress and animations continue rendering;
  • mouse-wheel/touchpad scrolling still works;
  • keyboard navigation (for example Tab) still works;
  • other Windows applications remain fully interactive;
  • mouse and touchpad hover/clicks stop working throughout the affected Codex window, including the title-bar controls.
  1. Without restarting Codex, inspect the main HWND using Win32 APIs.
  2. In the captured occurrence, the affected window showed:

IsWindowVisible(hwnd) = TRUE
IsWindowEnabled(hwnd) = FALSE
GetLastActivePopup(hwnd) = hwnd
GetWindow(hwnd, GW_ENABLEDPOPUP) = NULL

There is therefore no surviving enabled popup/modal to interact with.

  1. Calling EnableWindow(hwnd, TRUE) immediately restores mouse/touchpad interaction in the same running Codex window.
  2. No Codex restart is required and the existing task/session remains alive.

I have observed the same symptom on separate days and in both the Stable and Beta Windows desktop apps.

I do not yet know which modal/dialog operation initially leaves the parent HWND disabled. I can collect additional logs around the next occurrence if maintainers can suggest specific events or diagnostics to capture.

What is the expected behavior?

The Codex desktop app's main Windows HWND should remain enabled whenever there is no active modal or enabled popup.

If a native dialog or modal lifecycle is involved, closing, cancelling, destroying, or interrupting it should reliably re-enable the owning main window.

More specifically:

  • Closing or cancelling any Codex-triggered dialog must restore the parent window.
  • Destroying or disposing the dialog requester must not strand the parent at Enabled=False.
  • If no popup remains, the main window must not continue rejecting pointer input.
  • The user should never need to restart Codex or externally invoke user32!EnableWindow to regain control.

Additional information

This may share a root cause with #35866, which documents the same Win32 orphaned-window state in the Codex VS Code extension:

Visible=true
Enabled=false
LastActivePopup=self
EnabledPopup=0

The exact Win32 Enabled=False state was captured in the Stable standalone desktop app. I have observed the same user-visible unclickable-but-responsive symptom in both Stable and Beta channels, but the Win32 state has not yet been captured during a Beta occurrence.

Confirmed non-destructive workaround:

EnableWindow(mainHwnd, TRUE)

This immediately restores the existing window without restarting Codex or terminating the running app-server/session.

I have already ruled out:

  • external mouse/touchpad hardware;
  • stuck Win32 mouse capture (Capture=0x0);
  • window drag/resize state (MoveSize=0x0);
  • general Windows/system unresponsiveness;
  • a conventional renderer crash, since rendering, animations, scrolling and keyboard navigation continue.

The exact action that originally strands the HWND at Enabled=False is not yet known. I can capture narrowly filtered/redacted logs around the next occurrence if maintainers specify useful event names or timestamps.

Stable and Beta were not originally running together as a trigger. I opened the other channel only after the first channel became disabled so that I could continue working. Running both channels simultaneously is not required for the issue to occur.

View original on GitHub ↗