[Windows][26.825.6671.0] Main Chromium HWND is created hidden; ShowWindow immediately restores the UI

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

OpenAI.Codex 26.825.6671.0 (Microsoft Store MSIX)

Package identity:

OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0
Status: Ok
SignatureKind: Store

The packaged ChatGPT.exe reports Chromium file/product version 151.0.7922.174.

What subscription do you have?

Not relevant to this local pre-UI startup failure; the exact account tier was not verified.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64
Windows 11 25H2, build 26200.9168

Display adapters present:

NVIDIA GeForce RTX 4060 Laptop GPU — driver 32.0.15.9200
Intel UHD Graphics — driver 32.0.101.6790

The older OpenAI.ChatGPT-Desktop 1.2026.190.0 Store package is also installed side-by-side. The affected process path is unambiguously the OpenAI.Codex_26.825.6671.0 package.

What issue are you seeing?

Summary

Launching the Windows Codex desktop app starts a responsive Chromium process tree, but no application appears in Alt+Tab or on the taskbar. PowerShell reports MainWindowHandle = 0, and initially there are no renderer processes.

The important new diagnostic is that a valid top-level Chromium HWND has already been created. It is on-screen and has normal dimensions, but it remains hidden:

Owner PID: main packaged ChatGPT.exe
Class: Chrome_WidgetWin_0
Visible: False
Title: <empty>
Rect: 69,69,922,559

Calling Win32 ShowWindow(hwnd, SW_SHOW) followed by SetForegroundWindow(hwnd) immediately changes the application state:

• the native window becomes visible;
• multiple --type=renderer processes are spawned;
• the window title becomes ChatGPT;
• the application becomes usable;
• no reset, reinstall, cache deletion, or configuration change is required.

This indicates that AppX activation and native window creation both succeed, but the startup lifecycle fails to transition an already-created BrowserWindow/HWND from hidden to visible. MainWindowHandle = 0 is misleading here because .NET returns the main visible top-level window; direct Win32 enumeration proves that the hidden top-level window exists.

Process state before forcing the window visible

main ChatGPT.exe             running, Responding=True, MainWindowHandle=0
crashpad-handler             running
crashpad-handler             running
gpu-process                  running
network utility              running
storage utility              running
renderer                     NOT PRESENT

The main process remained active and consumed approximately 1.73 CPU seconds during a two-second sample, consistent with a high-CPU startup spin rather than an exited process.

The main process was launched through normal AppX activation with explorer.exe as its parent. Its command line contained no --hidden or start-minimized argument.

Process state immediately after ShowWindow

main ChatGPT.exe             MainWindowHandle != 0, title = ChatGPT
renderer                     spawned (multiple processes)
gpu-process                  still running
network/storage utilities    still running
application UI               visible and usable

The renderer processes appeared only after the existing hidden native window was shown.

Windows and package evidence

AppModel-Runtime recorded successful activation rather than an AppX launch failure:

Event 201: Created process for OpenAI.Codex_2p2nqsd0c76g0!App
Event 210: Created Desktop AppX container
Event 211: Added process to Desktop AppX container

No matching events were found in the Application log for:

Application Error 1000
Windows Error Reporting 1001
Application Hang 1002

The active Crashpad profile contained no crash report for this startup.

Checks that did not identify the cause

• AppX package status is Ok.
• The main window rectangle is valid and on-screen, so this is not an off-screen saved-bounds problem.
• config.toml does not contain approval_policy = "untrusted".
• No persisted ELECTRON_*, CHROME_*, NODE_OPTIONS, OZONE, or ANGLE environment override exists in HKCU/HKLM.
• There are no AppCompat layer flags for the packaged ChatGPT.exe.
• GPU and utility processes start normally.
• There is no crash, WER, or AppModel activation failure.
• Repair/reset/reinstall-style explanations do not fit the observed recovery: showing the already-existing HWND restores the same running process immediately.

Why this report is distinct from related reports

There are several related headless-startup reports, including #41523, #41096, #41482, #41073, and #38766. Most infer that a window has not yet been created because MainWindowHandle = 0, or focus on updater/runtime extraction delays.

This report adds a narrower and directly observed state transition:

1. the main native Chrome_WidgetWin_0 already exists with valid bounds;
2. it is specifically hidden (IsWindowVisible == false);
3. showing that same HWND immediately triggers renderer creation and restores the UI.

A shorter version of this diagnostic was also added to #41523. This standalone report consolidates the full environment, exclusions, reproduction evidence, and suggested engineering checks so the hidden-window lifecycle failure can be tracked independently.

What steps can reproduce the bug?

1. Install or update the Microsoft Store Codex app to 26.825.6671.0.
2. Launch Codex from the Start menu.
3. Observe that several packaged ChatGPT.exe processes start, but no UI appears and the app is absent from Alt+Tab.
4. Confirm the initial process state:

Get-CimInstance Win32_Process |
  Where-Object {
    $_.Name -eq 'ChatGPT.exe' -and
    $_.ExecutablePath -like '*OpenAI.Codex*'
  } |
  Select-Object ProcessId, ParentProcessId, CommandLine

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

5. Enumerate all top-level windows with Win32 EnumWindows, filter by the packaged main-process PID, and inspect GetClassName, IsWindowVisible, and GetWindowRect.
6. Observe the hidden Chrome_WidgetWin_0 with a normal on-screen rectangle.
7. Call ShowWindow(hwnd, SW_SHOW) and SetForegroundWindow(hwnd) for that window.
8. Observe that the UI appears immediately and renderer processes are created.

A minimal PowerShell diagnostic/recovery sample is below. It deliberately targets only the main ChatGPT.exe whose executable path belongs to OpenAI.Codex:

Add-Type @'
using System;
using System.Text;
using System.Runtime.InteropServices;

public static class CodexWindowProbe {
    public delegate bool EnumWindowsProc(IntPtr hwnd, IntPtr lParam);

    [DllImport("user32.dll")]
    public static extern bool EnumWindows(EnumWindowsProc callback, IntPtr lParam);

    [DllImport("user32.dll")]
    public static extern uint GetWindowThreadProcessId(IntPtr hwnd, out uint processId);

    [DllImport("user32.dll")]
    public static extern int GetClassName(IntPtr hwnd, StringBuilder text, int maxCount);

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

    [DllImport("user32.dll")]
    public static extern bool ShowWindow(IntPtr hwnd, int command);

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

$main = Get-CimInstance Win32_Process |
  Where-Object {
    $_.Name -eq 'ChatGPT.exe' -and
    $_.ExecutablePath -like '*OpenAI.Codex*' -and
    $_.CommandLine -notmatch '--type='
  } |
  Select-Object -First 1

[CodexWindowProbe]::EnumWindows({
    param($hwnd, $lParam)

    $ownerPid = 0
    [CodexWindowProbe]::GetWindowThreadProcessId($hwnd, [ref]$ownerPid) | Out-Null

    if ($ownerPid -eq $main.ProcessId) {
        $className = [Text.StringBuilder]::new(256)
        [CodexWindowProbe]::GetClassName($hwnd, $className, 256) | Out-Null

        if ($className.ToString() -eq 'Chrome_WidgetWin_0') {
            [pscustomobject]@{
                PID = $ownerPid
                Handle = ('0x{0:X}' -f $hwnd.ToInt64())
                VisibleBefore = [CodexWindowProbe]::IsWindowVisible($hwnd)
            }

            # Diagnostic intervention used in this report:
            [CodexWindowProbe]::ShowWindow($hwnd, 5) | Out-Null # SW_SHOW
            [CodexWindowProbe]::SetForegroundWindow($hwnd) | Out-Null
        }
    }

    return $true
}, [IntPtr]::Zero) | Out-Null

The exact trigger may be tied to the first launch after an automatic update. The failure was observed after the package was updated on the same day. The window-level state and immediate recovery are deterministic once the app is in the affected headless state.

What is the expected behavior?

The desktop app should always make its main window visible after successful AppX activation and native window creation.

If pre-renderer initialization, updater policy, runtime extraction, shell-environment discovery, or another startup gate must complete first, the app should display a bounded splash/progress/recovery window rather than leave a fully hidden top-level window and high-CPU background process indefinitely.

If the intended ready-to-show transition does not occur within a bounded interval, the app should recover by showing the existing main window with an actionable loading/error state.

Additional information

Suggested engineering checks:

1. Log native BrowserWindow/HWND creation separately from renderer creation, did-finish-load, ready-to-show, and the final show() call.
2. Record the reason whenever the main window remains hidden after AppX activation.
3. Check whether a startup prerequisite is waiting for visibility while visibility itself waits for ready-to-show, creating a circular dependency.
4. Check the automatic-update / first-launch path for a missed or deferred show() call.
5. Add a bounded watchdog: if a valid main HWND exists but stays hidden and no renderer becomes ready, show a minimal recovery UI instead of remaining headless.
6. Consider emitting a Windows-specific startup diagnostic event containing HWND-created, HWND-visible, renderer-created, and ready-to-show timestamps.

Related issues:

• #41523 — post-update background launch with MainWindowHandle=0
• #41096 — no renderer process and high-CPU main-process spin
• #41482 — background processes start but no GUI appears
• #41073 — headless launch with MainWindowHandle=0
• #38766 — prolonged headless startup before recovery

Privacy: this report intentionally excludes usernames, account identifiers, Windows SIDs, local project paths, conversation content, session transcripts, raw browser-profile data, and complete logs. Additional sanitized diagnostics can be provided if requested.

Start with AppX activation and trace the Windows startup lifecycle through BrowserWindow/HWND creation, renderer creation, did-finish-load, ready-to-show, and the final show() call. Reproduce the hidden Chrome_WidgetWin_0 state with the PowerShell Win32 probe. Done means the main window becomes visible after activation, or a bounded recovery UI appears when startup cannot complete.