›_ Codex Issues
Codex Issues / #17205

Windows app: official pinned taskbar icon does not restore hidden main window after close-to-background

Open 💬 6 comments Opened Apr 9, 2026 by Nilhan-DeMel
💡 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.406.3494.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, closing the visible Codex window leaves the app running in the background, but clicking the official pinned taskbar icon does not restore the hidden main window.

The only reliable recovery is to end the Codex processes in Task Manager and cold-start the app again.

I verified this after restoring the taskbar pin to the official packaged app target, so this does not appear to be a bad shortcut/pin configuration.

What steps can reproduce the bug?

  1. Launch Codex from the official pinned taskbar icon.
  2. Confirm the main Codex window is visible.
  3. Close the visible Codex window normally.
  4. Confirm Codex remains alive in the background.
  5. Click the same official pinned taskbar icon again.
  6. Observe that no visible Codex window returns.

What is the expected behavior?

Clicking the official pinned taskbar icon should restore the existing hidden Codex window or otherwise show a visible Codex UI without requiring Task Manager cleanup.

Additional information

  • Package full name: OpenAI.Codex_26.406.3494.0_x64__2p2nqsd0c76g0
  • Package family: OpenAI.Codex_2p2nqsd0c76g0
  • Official pinned shortcut used:

C:\Users\Nilhan.dev\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Codex.lnk

Fresh local repro evidence:

  • Before close, the main top-level window existed as:
  • handle: 0x290672
  • title: Codex
  • class: Chrome_WidgetWin_1
  • visible: true
  • After close, the same main window handle 0x290672 still existed but visible=false
  • After clicking the official pinned taskbar shortcut, the same main window handle 0x290672 still existed and still had visible=false
  • Visible main window count after taskbar relaunch: 0

So the app is not fully gone; the primary window remains alive but hidden, and the official taskbar relaunch path does not bring it back.

I also checked a few adjacent paths:

  • Launching through shell:AppsFolder\\OpenAI.Codex_2p2nqsd0c76g0!App showed the same behavior
  • Current logs during this repro did not show the cache/router errors from some other Windows launch failures

Local bundle inspection suggests the tray button path explicitly calls window visibility logic, while second-instance relaunch appears to route through deep-link argument handling. That may explain why the hidden window survives but is not restored by a plain relaunch.

This feels related to the current Windows background/stale-process family, but narrower than the existing reports because the key failure here is:

official pinned taskbar icon -> existing hidden main window is not restored

I have a local evidence pack with screenshots and a JSON capture of the window state before close, after close, and after taskbar relaunch if that would help.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

  • #16540
  • #15949
  • #16618

Powered by Codex Action

Nilhan-DeMel · 3 months ago

Repair did not resolve this on my machine.

Post-repair verification on 2026-04-09:

  • Windows build: 10.0.26200.0 x64
  • Codex version remained: 26.406.3494.0
  • The official pinned shortcut still reproduced the bug on the first fresh attempt after repair
  • The same main window handle stayed alive but hidden:
  • before close: visible true
  • after close: visible false
  • after clicking the official pinned taskbar icon: still visible false
  • The post-repair verification file is local, but the key result was:
  • success=false on attempt 1
  • allThreeSucceeded=false

Additional clue:

  • I also checked for a visible codex protocol registration after repair and still found no HKCU\\Software\\Classes\\codex or HKCR\\codex key on this machine.

So at least on this Windows install, the official MSIX Repair action does not fix the hidden-window/taskbar-reactivation problem.

Nilhan-DeMel · 3 months ago

Reset also did not fix this.

I initially had one post-reset automation pass that looked promising, but on a stricter follow-up check using a more realistic close path (Alt+F4) the original bug reproduced exactly again:

  • before close: visible true
  • after close: visible false
  • after clicking the official pinned taskbar icon: still visible false
  • same main window handle stayed alive the whole time
  • result: success=false

So the current verified state is:

  • Repair failed
  • wsreset.exe failed
  • Reset failed

I also saved the stricter post-reset result locally as post-reset-direct-close-verification.json in the same evidence folder.

hashem-reyi · 3 months ago

I am also facing the same issue

FalseVergil · 3 months ago

I am also facing the same issue

PaulStSmith · 3 months ago

<img width="352" height="163" alt="Image" src="https://github.com/user-attachments/assets/40d4c7ee-9d70-4e02-b9f6-b665696c6c3b" />

Apparently, the issue has been fixed on 26.415.20818
I just tested and both “New chat” and close/reopen are working as they should.
However, “New chat” creates a new chat for the current project, not a totally new one. But this is the standard behavior when opening Codex, if defaults to the last opened project.