codex - 💡(How to fix) Fix Codex Desktop thread summary panel auto-opens on right-edge hover with no opt-out [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#21140Fetched 2026-05-06 06:26:04
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
2
Author
Timeline (top)
cross-referenced ×3labeled ×2commented ×1

Code Example

._panel_mvlmq_1:after {
  content: "";
  z-index: 10;
  pointer-events: auto;
  width: 36px;
  position: absolute;
  top: 0;
  bottom: 0;
  right: 0;
}

._panel_mvlmq_1:hover,
._panel_mvlmq_1._open_mvlmq_31 {
  opacity: var(--thread-summary-panel-progress);
  pointer-events: auto;
}

._panel_mvlmq_1:hover ._content_mvlmq_36,
._panel_mvlmq_1._open_mvlmq_31 ._content_mvlmq_36 {
  transform: translate(0);
}
RAW_BUFFERClick to expand / collapse

What version of Codex is running?

Codex Desktop app 26.429.30905 (CFBundleVersion 2345) on macOS.

What steps can reproduce the bug?

  1. Open Codex Desktop with a local Git-backed conversation.
  2. Move the mouse to the far right edge of the Codex window.
  3. A floating thread summary panel opens automatically. In my case it shows sections such as:
    • Branch details
    • Changes
    • Git actions
    • Create pull request
    • Sources / Web search

What is the expected behavior?

The panel should not open from incidental right-edge mouse movement unless the user has opted into that behavior.

At minimum, there should be a setting or persisted preference to disable the right-edge hover opener. Ideally the panel should open only via an explicit control, keyboard command, or pinned state.

What do you see instead?

Moving the cursor to the far right side of the screen/window opens the panel automatically. I do not see a way to turn this behavior off, so it is easy to trigger accidentally while using Codex or moving between windows.

Additional information

I inspected the installed Desktop app bundle to identify the behavior. The relevant UI appears to be the thread summary panel, not the pet/avatar overlay.

In the bundled webview assets, the rendered strings are associated with the thread summary panel:

  • codex.localConversation.gitSummary.title -> Branch details
  • localConversationPage.gitActions -> Git actions
  • codex.localConversation.gitSummary.createPullRequest -> Create pull request
  • codex.localConversation.sources.title -> Sources
  • codex.localConversation.sources.webSearch -> Web search

The bundled CSS appears to intentionally create a hover target at the right edge:

._panel_mvlmq_1:after {
  content: "";
  z-index: 10;
  pointer-events: auto;
  width: 36px;
  position: absolute;
  top: 0;
  bottom: 0;
  right: 0;
}

._panel_mvlmq_1:hover,
._panel_mvlmq_1._open_mvlmq_31 {
  opacity: var(--thread-summary-panel-progress);
  pointer-events: auto;
}

._panel_mvlmq_1:hover ._content_mvlmq_36,
._panel_mvlmq_1._open_mvlmq_31 ._content_mvlmq_36 {
  transform: translate(0);
}

This suggests the panel auto-opening is implemented as an invisible 36px hover gutter. A possible fix would be to gate that :after hover strip and :hover open behavior behind a user preference, or remove the hover-open behavior and rely on explicit open/pin/toggle state instead.

I looked in the public openai/codex repo but could not find the Desktop webview source for this panel, only the bundled app output locally, so I cannot submit a clean source PR from the public checkout.

extent analysis

TL;DR

The issue can be fixed by modifying the CSS to gate the hover-open behavior behind a user preference or removing it altogether.

Guidance

  • Investigate the CSS code and identify the specific classes and selectors responsible for the hover-open behavior, such as ._panel_mvlmq_1:after and ._panel_mvlmq_1:hover.
  • Consider adding a user preference to toggle the hover-open behavior, which would require modifying the CSS to include a conditional class or attribute.
  • Alternatively, remove the hover-open behavior and rely on explicit open/pin/toggle state instead, which would involve modifying the CSS to remove the :hover pseudo-class.
  • Verify the changes by testing the updated CSS in the Desktop app and ensuring the panel no longer opens automatically on hover.

Example

/* Example of how to gate the hover-open behavior behind a user preference */
._panel_mvlmq_1.pref-hover-enabled:after {
  content: "";
  z-index: 10;
  pointer-events: auto;
  width: 36px;
  position: absolute;
  top: 0;
  bottom: 0;
  right: 0;
}

._panel_mvlmq_1.pref-hover-enabled:hover,
._panel_mvlmq_1._open_mvlmq_31 {
  opacity: var(--thread-summary-panel-progress);
  pointer-events: auto;
}

Notes

The provided CSS code snippet suggests that the hover-open behavior is implemented as an invisible 36px hover gutter. However, without access to the public openai/codex repo source code, it's difficult to provide a complete solution.

Recommendation

Apply a workaround by modifying the CSS to remove the hover-open behavior, as it seems to be the most straightforward solution. This would require removing the :hover pseudo-class and relying on explicit open/pin/toggle state instead.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop thread summary panel auto-opens on right-edge hover with no opt-out [1 comments, 2 participants]