openai / openai/codex

[Windows][Desktop] Right-pane tabs can become stale ghost tabs that lose their × close control entirely

Open
#41,653 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

app bug windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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

Powered by Codex & OWL, Version 26.825.41651 (released 29 Aug 2026)

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Intermittently, tabs in the Codex desktop right-hand pane become stale "ghost" tabs that can no longer be dismissed individually.

Observed behaviour

  • The affected tab remains visible in the right-pane tab strip.
  • Its × close control disappears entirely. The button is not rendered on the tab at all, so there is nothing to click. This is not a hover-only affordance: hovering over an affected tab does not reveal a close control either. This is distinct from a close button that is still visible but does not respond when clicked.
  • Normal tabs sitting immediately alongside the affected tabs still show and use their × correctly, so this is not the whole tab strip becoming unresponsive.
  • The affected tab is also completely inert. Clicking it produces no response and it cannot be selected, so there is no way to focus it and dismiss it by some other route.
  • The individual tab cannot be closed by any route I have found.
  • Closing and reopening the entire right-hand pane clears the stuck tabs. That is currently the only workaround I know of.
  • I have seen this with more than one kind of right-pane surface, including browser/preview tabs and Plan-related tabs, so it does not appear tied to one particular web page or a single content type.

On cause

I am not claiming a root cause. As an observation only, the pattern (the tab entry persisting in the strip while its close affordance is gone, and a full pane teardown clearing it) looks more like a tab/pane lifecycle or state-management problem than a rendering hang. That is inference from the UI, not a confirmed diagnosis. I have no logs or error messages to attach.

Relationship to existing issues

This appears related to, but materially different from, #41417 ("Desktop: closing an IAB tab should not depend on a responsive renderer"). In #41417 the close button is still present and clicking it does nothing because the renderer has hung. In my case the close control is not rendered at all, including on hover, the affected tab does not respond to clicks at all, neighbouring tabs in the same strip stay fully interactive, and the affected surfaces are not limited to a hung in-app browser renderer. #33484 and #33160 describe the same close-button-present-but-unresponsive shape and are likewise distinct from this report.

Screenshot

The two tabs inside the green highlight are stuck ghost tabs with no ×. The tab immediately to their left is a normal tab in the same strip and still shows its ×. Site names and favicons are redacted.

Image
What steps can reproduce the bug?

I do not have a deterministic reproduction. This is intermittent, and I have not identified a shorter, reliable sequence that triggers it. The following is the best description of the conditions under which I have observed it, not a guaranteed recipe.

  1. Use Codex normally with the right-hand pane open.
  2. Over the course of a session, open and close various right-pane surfaces/tabs, including browser/preview and/or Plan-type content.
  3. After some usage, one or more tabs remain in the tab strip but no longer show a × close control.
  4. Attempt to close an affected tab, including hovering over it to bring up a close control. No × appears on hover, and the tab itself does not respond to clicks.
  5. Close and reopen the entire right-hand pane.
  6. The ghost tabs are cleared.

Frequency: intermittent. I cannot currently say how many tabs, which sequence of opens and closes, or how long a session needs to run before it occurs. I have deliberately not invented a deterministic sequence here; a shorter reproduction has not yet been identified.

What is the expected behavior?

Every closable right-pane tab should retain a functioning close control for as long as it is present in the tab strip.

  • Closing a tab should remove it cleanly from the tab strip.
  • A tab should never remain permanently in the UI in a state where it cannot be individually dismissed.
  • If a surface's own close path fails, there should still be a way to dismiss that single tab.
  • Users should not have to reset the entire right-hand pane in order to clear stale tabs.
Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source files, tests, or entry points are identified in the report. Start by reproducing the intermittent ghost-tab state while opening and closing browser/preview and Plan tabs, then trace the right-pane tab lifecycle. Done means affected tabs retain a working individual close path and no longer require closing and reopening the entire pane.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.