›_ Codex Issues
Codex Issues / #25826

Windows Desktop: maximized window spills onto adjacent monitors in multi-monitor setup

Open 💬 6 comments Opened Jun 2, 2026 by claell

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

Codex Desktop on Windows, Microsoft Store/AppX package:

  • OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

What subscription do you have?

Unknown / not relevant.

What platform is your computer?

Windows 11 Education, version 10.0.26200, build 26200, 64-bit.

Multi-monitor setup with the Codex window maximized on the center monitor and adjacent displays connected on both the left and right sides.

Display/GPU devices present on this machine:

  • NVIDIA RTX PRO 1000 Blackwell Generation Laptop GPU, driver 32.0.15.9636
  • Intel(R) Arc(TM) Pro 140T GPU (16GB), driver 32.0.101.8724
  • Virtual display drivers are also present: MirrorOp Virtual Graphics Adaptor, Meta Virtual Monitor, Virtual Desktop Monitor

What issue are you seeing?

When Codex Desktop is maximized on the center monitor in a multi-monitor Windows setup, the maximized window appears to extend slightly beyond the target monitor's bounds. A thin strip or border of the Codex window becomes visible on the adjacent left and/or right monitor at the shared monitor edge.

This does not look like the same symptom as the Windows maximized transparency/sidebar repaint reports where content behind Codex shows through inside the app window. In this case, the visible problem is that the maximized Codex window itself appears too large or offset relative to the monitor it was maximized on, so part of the window leaks into neighboring monitor coordinate space.

The current version is still affected. I believe the previous version was already affected as well, but I do not know the exact introduction point.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows with a multi-monitor setup.
  2. Place the Codex window on the center monitor.
  3. Maximize the Codex window.
  4. Look at the shared edges on the adjacent left and right monitors.

Observed result:

  • Codex appears maximized on the center monitor, but a thin strip/border of the Codex window is visible on one or both adjacent monitors.
  • Restoring the window avoids the visible spillover.

What is the expected behavior?

Maximizing Codex on one monitor should constrain all visible window pixels to that monitor's native maximized bounds / working area. No part of the Codex window frame, border, transparent region, or client surface should appear on adjacent monitors.

Additional information

I searched existing openai/codex issues before filing. The closest open issues I found are related to Windows maximized transparency, stale repainting, or sidebar/title-bar transparency, but they appear to describe a different symptom:

  • #25513: Codex Desktop on Windows: rendering freezes/transparency when maximized
  • #25217: Windows: maximized Codex window shows transparent/desktop bleed-through after 26.527.3686.0 update
  • #25347: Windows Codex app header and left sidebar become transparent when maximized
  • #25754: Codex App: sidebar and top menu become transparent when maximized on Windows

Those reports may share the same maximize-related code path, but this issue is specifically about the maximized window visibly spilling onto adjacent monitors.

View original on GitHub ↗

6 Comments

MtkN1 · 1 month ago

<img width="2199" height="1080" alt="Image" src="https://github.com/user-attachments/assets/27d47b9d-bde4-44b9-8f4d-c7f04d824cee" />

Here is a screenshot illustrating the issue. The Codex app is maximized on the left display. The area outlined in red is already part of the adjacent display, but a thin strip of the Codex window extends into it.

today080221 · 1 month ago

Adding another affected Windows multi-monitor setup with exact Win32/DWM measurements. No screenshots attached because my captures include personal UI content.

Environment:

  • Codex Desktop package: OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0
  • Codex.exe ProductVersion/FileVersion: 149.0.7827.54
  • OS: Windows 11 Pro for Workstations, 10.0.26200 Build 26200
  • Displays: three 2560x1440 monitors at 100% scaling
  • primary: X=0, Y=0, W=2560, H=1440, work area H=1392
  • left: X=-2560, Y=0, W=2560, H=1440, work area H=1392
  • right: X=2560, Y=0, W=2560, H=1440, work area H=1392
  • Windows transparency effects enabled
  • DWM attributes on the Codex main window: SystemBackdropType=2, UseImmersiveDarkMode=1, WindowCornerPreference=2

Observed while Codex is maximized on the left monitor:

  • GetWindowRect / DWMWA_EXTENDED_FRAME_BOUNDS: Left=-2568, Top=-8, Right=8, Bottom=1400, W=2576, H=1408
  • Client rect: W=2562, H=1394

The target monitor bounds are X=-2560..0, so the maximized window extends 8 px into the adjacent monitor. It also extends 8 px beyond the top edge compared with the visible monitor/work-area path.

Additional related symptom: when Codex changes focus state, the sidebar/top chrome visibly repaints/flashes while the main content area remains stable. That focus-state repaint looks related to the translucent/Mica behavior discussed in #25154 and #25513.

kevinzien1107-ctrl · 26 days ago

I can reproduce this on a newer Codex Desktop build as well.

Environment:

  • Codex package: OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0
  • Codex executable product/file version: 149.0.7827.115
  • OS: Windows 11 Pro for Workstations, version 10.0.26200, 64-bit
  • GPU: NVIDIA GeForce RTX 4090 Laptop GPU, driver 32.0.16.1062
  • Display setup: dual monitor
  • Primary: {X=0,Y=0,Width=1707,Height=1067}, working area {X=0,Y=0,Width=1707,Height=1019}
  • Secondary: {X=1707,Y=0,Width=1707,Height=960}, working area {X=1707,Y=0,Width=1707,Height=912}

Observed behavior:

  • When Codex is maximized on the primary display with the native maximize button, a thin strip remains visible on the left edge of the secondary display.
  • Programmatically inspecting the window after native maximize shows the window rect extending beyond the primary monitor bounds: L=-7,T=-7,R=1714,B=1026,W=1721,H=1033, while the primary monitor bounds are 0..1707 horizontally.
  • Restoring the window and manually sizing it inside the work area avoids the spillover, which points to the native maximized-window bounds/frame path rather than the monitor arrangement itself.

Expected behavior:

  • Native maximized Codex windows should not render any visible pixels on adjacent monitors.
BoillingFish · 12 days ago

Additional reproduction details from another Windows user:

  • Codex Windows app package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0
  • OS: Windows 11 Pro for Workstations, version 10.0.26200, build 26200, 64-bit
  • Multi-monitor setup: 3 monitors
  • Display scaling: all three monitors are set to 200% scaling, so this does not appear to require mixed DPI scaling
  • Reproduction persists after restarting Codex
  • Reproduction also occurs when Codex is moved to the primary display and then maximized
  • Other apps on the same monitor layout do not show the same overflow behavior

Observed behavior: when Codex is maximized, the window border/edge still appears on adjacent displays instead of being fully clipped to the target monitor bounds.

This points more toward Codex Desktop's Windows maximize/window-bounds handling than a user display-scaling mismatch.

UPSOKen · 9 days ago

Still happening on the new ChatGPT/Codex combined application.

gilmarvitor · 4 days ago

I reproduced this issue and was able to capture the exact technical measurements of the Codex Desktop window maximized vs. restored, including the monitor rectangles.

Relevant topology (two of four monitors on this machine):

Monitor where Codex was open (secondary, vertical):

  • Resolution: 1080 × 1920, 100% scale, effective DPI 96×96
  • Virtual coordinates: left -1080, top -173, right 0, bottom 1747
  • Working area: left -1080, top -173, right 0, bottom 1699 (1080 × 1872)

Adjacent horizontal monitor to the right (primary):

  • Resolution: 3440 × 1440, 100% scale, effective DPI 96×96
  • Virtual coordinates: left 0, top 0, right 3440, bottom 1440
  • Working area: left 0, top 0, right 3440, bottom 1392

Both monitors use 100% scale/96 DPI, so this reproduction does not depend on mixed-DPI.

Restored window (no overflow), before maximizing:

  • GetWindowRect = DWMWA_EXTENDED_FRAME_BOUNDS: left -1064, top -173, right -16, bottom 1699 (1048 × 1872)
  • 16px margin on each side inside the vertical monitor; no strip appears on the horizontal monitor.

Maximized window (with overflow):

  • GetWindowRect = DWMWA_EXTENDED_FRAME_BOUNDS: left -1088, top -181, right 8, bottom 1707 (1096 × 1888)
  • MonitorFromWindow/GetMonitorInfo → rcMonitor: left -1080, top -173, right 0, bottom 1747 (1080×1920); rcWork: left -1080, top -173, right 0, bottom 1699 (1080×1872)

Measured difference: when maximized, the window overflows 8px past the monitor on the left, 8px above, 8px below the working area, and — most notably — 8px to the right of the vertical monitor's boundary (which ends at X=0), spilling those 8px onto the adjacent horizontal monitor. The DWMWA_EXTENDED_FRAME_BOUNDS value is identical to GetWindowRect, including the 8px overflow, which indicates that DWM itself reports the extended frame outside the monitor bounds, not just a logical rectangle.

After taking these measurements, I manually restored the window and the bounds returned to the original, non-overflowing state, confirming that native maximization is what computes a rectangle 16px larger (in width and height) than the destination monitor's working area, with 8px of overflow per side.

I did not change any monitor settings, drivers, DWM configuration, registry, or transparency settings during this test.