[Windows] Computer Use can leave Codex desktop main window permanently disabled and unclickable

What version of the Codex App are you using?

Codex Desktop for Windows.

Observed package version from the running process:

OpenAI.Codex_26.903.9818.0

Also observed:

codex-command-runner-0.153.4.exe

Platform

Windows x64

What issue are you seeing?

After Codex uses Computer Use several times during a session, the Codex/ChatGPT desktop application can suddenly become completely unclickable.

The application itself is not frozen:

• The UI is still rendered normally.
• Codex/background tasks continue running.
• The window can still be seen and switched to.
• Other applications on Windows continue working normally.

However, clicking anywhere inside the Codex desktop window does nothing and Windows plays the standard warning/beep sound on each click.

Keyboard/window recovery attempts such as Alt+Tab, Win+Tab, Esc, and trying to locate an off-screen modal did not resolve the problem.

I eventually inspected the main Codex window through Win32 and found that Windows had explicitly marked the main application window as disabled.

Diagnostic evidence

The visible main ChatGPT/Codex process was:

PID     : 29372
Title   : ChatGPT
Handle  : 263264
Enabled : False
Visible : True

This was checked using:

Add-Type @"
using System;
using System.Runtime.InteropServices;

public class Win32WindowCheck
{
    [DllImport("user32.dll")]
    public static extern bool IsWindowEnabled(IntPtr hWnd);

    [DllImport("user32.dll")]
    public static extern bool IsWindowVisible(IntPtr hWnd);
}
"@

$p = Get-Process -Id 29372

[PSCustomObject]@{
    PID     = $p.Id
    Title   = $p.MainWindowTitle
    Handle  = $p.MainWindowHandle
    Enabled = [Win32WindowCheck]::IsWindowEnabled($p.MainWindowHandle)
    Visible = [Win32WindowCheck]::IsWindowVisible($p.MainWindowHandle)
}

The result was:

Enabled : False
Visible : True

There was no visible modal/dialog that I could interact with.

The running process tree also contained multiple ChatGPT.exe and codex.exe processes, along with:

codex-code-mode-host.exe
codex-command-runner-0.153.4.exe

There was no obvious codex-computer-use.exe process remaining by the time the problem was diagnosed.

Current workaround / temporary fix

Without terminating Codex or restarting the desktop application, manually re-enabling the existing main window immediately restored mouse input and preserved the running Codex task/session.

A PID-specific version that fixed the affected session was:

Add-Type @"
using System;
using System.Runtime.InteropServices;

public static class Win32ChatGPTFix
{
    [DllImport("user32.dll")]
    public static extern bool EnableWindow(IntPtr hWnd, bool bEnable);

    [DllImport("user32.dll")]
    public static extern bool SetForegroundWindow(IntPtr hWnd);
}
"@

$p = Get-Process -Id 29372

[Win32ChatGPTFix]::EnableWindow($p.MainWindowHandle, $true)
[Win32ChatGPTFix]::SetForegroundWindow($p.MainWindowHandle)

Immediately after EnableWindow(..., true), the Codex desktop UI became clickable again.

For other affected users, the PID can first be identified with:

Get-Process ChatGPT | Select-Object Id, MainWindowTitle, MainWindowHandle

The visible main window is the process with a non-empty MainWindowTitle / non-zero MainWindowHandle. That PID can then be used in the workaround above.

A more automatic workaround is:

Add-Type @"
using System;
using System.Runtime.InteropServices;

public static class Win32ChatGPTFix
{
    [DllImport("user32.dll")]
    public static extern bool EnableWindow(IntPtr hWnd, bool bEnable);

    [DllImport("user32.dll")]
    public static extern bool SetForegroundWindow(IntPtr hWnd);
}
"@

$p = Get-Process ChatGPT |
    Where-Object { $_.MainWindowHandle -ne 0 -and $_.MainWindowTitle } |
    Select-Object -First 1

if ($p) {
    [Win32ChatGPTFix]::EnableWindow($p.MainWindowHandle, $true)
    [Win32ChatGPTFix]::SetForegroundWindow($p.MainWindowHandle)
}

This is only a workaround. If a legitimate modal is actually present, manually re-enabling its owner may bypass normal Windows modal behavior, so the underlying lifecycle bug should still be fixed in the app.

Steps to reproduce

I have encountered this more than once during extended Codex sessions:

1. Start Codex Desktop on Windows.
2. Run a task that uses Computer Use.
3. Allow Computer Use to interact with applications/windows multiple times.
4. Continue working normally.
5. Eventually return to or interact with the Codex desktop window.
6. The Codex UI is still visible and running, but nothing inside the application can be clicked.
7. Windows plays the warning/beep sound whenever the disabled Codex window is clicked.
8. Check the Codex main HWND using IsWindowEnabled().
9. It reports False.
10. Call EnableWindow(hwnd, TRUE).
11. The application immediately starts accepting input again.

The number of Computer Use operations required before this happens does not appear to be deterministic.

Expected behavior

After Computer Use completes, fails, times out, or dismisses any modal operation, the Codex desktop main window should always have its Win32 enabled state restored.

A failed or destroyed Computer Use dialog should not leave its owner window permanently disabled.

If Codex disables the main window while a modal is active, cleanup should guarantee that the window is re-enabled even if:

• Computer Use terminates unexpectedly
• a modal is destroyed
• a helper process exits
• an operation times out
• the target application disappears
• Computer Use encounters an exception

Actual behavior

The Codex main window remains:

Visible = True
Enabled = False

indefinitely.

This makes the entire application appear frozen even though the process and active Codex task are still healthy.

Restarting/killing Codex should not be necessary because simply restoring the Win32 enabled state completely fixes the UI.

Impact

This is especially disruptive during long-running Codex tasks.

A user may assume Codex has frozen and force-close the application, potentially interrupting an active long-running task, even though the task itself is still running normally.

Because the application still renders correctly, it is also difficult for a user to understand why mouse input suddenly stops working.

Possible area to investigate

There may be an unbalanced Windows modal/owner-window lifecycle similar to:

EnableWindow(mainWindow, FALSE)

-> Computer Use / modal operation
-> modal/helper closes unexpectedly
-> cleanup path does not execute

EnableWindow(mainWindow, TRUE)  // never called

It may be worth ensuring that owner-window re-enabling happens in a guaranteed cleanup/finally path whenever Computer Use temporarily disables the Codex main window.

Related issue

Possibly related to #43833, which also observes a disabled owner window during Windows Computer Use modal handling, although this report is different:

In this case, the Codex application's own main window remains permanently disabled after Computer Use, there is no usable visible modal, and manually calling EnableWindow(..., TRUE) immediately restores the application.

Start by tracing the Windows Computer Use modal and owner-window lifecycle, focusing on the Win32 EnableWindow and IsWindowEnabled entry points mentioned in the report. Reproduce the issue after an unexpected modal or helper termination and inspect the cleanup paths. Done means the main HWND is re-enabled after completion, failure, timeout, destruction, or helper exit without restarting the app.