›_ Codex Issues
Codex Issues / #31018

macOS Codex desktop app: window controls are overlapped at 100% zoom

Open 💬 2 comments Opened Jul 3, 2026 by mounteee
💡 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.623.101652

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 22.6.0 x86_64 i386

What issue are you seeing?

macOS Codex desktop app: at 100% zoom, the top-left window controls are overlapped by the app header/sidebar controls. At 90% zoom it no longer happens.

Steps to reproduce:

  1. Open Codex desktop app on macOS.
  2. Set zoom to 100%.
  3. Look at the top-left window controls.

Expected:
The macOS window controls should remain visible and unobstructed.

Actual:
The window controls are partially overlapped by the Codex header/sidebar controls.

Workaround:
Set zoom to 90%.

<img width="646" height="388" alt="Image" src="https://github.com/user-attachments/assets/1b925835-ea80-423f-a305-c53b508c79fd" />

What steps can reproduce the bug?

  1. Open the Codex desktop app on macOS.
  2. Set the app zoom to 100%.
  3. Look at the top-left corner of the app window.

Result:
The macOS window controls are overlapped by the Codex header/sidebar controls.

Expected:
The macOS window controls should remain visible and unobstructed.

Additional note:
If the app zoom is changed to 90%, the overlap no longer happens.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #29738

Powered by Codex Action

mikew221 · 15 days ago

<img width="552" height="152" alt="Image" src="https://github.com/user-attachments/assets/2797d87c-23db-499d-8c46-960d0cd68fc6" />

I can reproduce this on Codex 26.803.61601 (build 6396), Electron 42.3.0,
macOS 13.7.8 / Darwin 22.6.0, Intel x86_64. At 100% zoom the lower edge of
the traffic-light controls is clipped; 90% renders normally.

I inspected the packaged Electron bundle and found a likely root cause. The app
uses titleBarStyle: "hiddenInset" and computes the native traffic-light y
coordinate from renderer zoom:

y = round((46 * windowZoom - 14) / 2)

The main process then calls setWindowButtonPosition(...) after every renderer
zoom change. This produces y=14 at 90%, y=16 at 100%, y=18 at 110%, and y=28
at 150%. That exactly matches the 90% workaround and also appears consistent
with the hit-target drift reported in #29738 and #31397.

The native AppKit controls and renderer content should not share a zoom-scaled
coordinate. My proposed fix is to omit the custom macOS trafficLightPosition
and stop calling setWindowButtonPosition() on renderer zoom changes, allowing
Electron/AppKit to use the OS-compatible hiddenInset position.

If the custom horizontal inset is required, a fixed, cross-version-tested native
position should be used instead. Windows and Linux can keep their existing
zoom-scaled titleBarOverlay behavior.

Suggested regression matrix:

  • 90%, 100%, 110%, and 150% app zoom
  • normal, maximized, and fullscreen window states
  • macOS 13 on Intel
  • current macOS on Apple Silicon
  • verify both visual positioning and native hover/click hit targets

I would be happy to prepare a focused PR with tests if a maintainer confirms
this direction and invites the contribution. The public repository does not
appear to contain the Electron desktop source.