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

<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.

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.

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.

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.

Still happening on the new ChatGPT/Codex combined application.

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.

Confirming this remains reproducible on a newer build as of 2026-07-27.

Environment:

• Codex package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Windows version 25H2, build 26200.8875, x64
• Intel Arc 140V GPU, driver 32.0.101.8508
• Dual displays in extended mode, both at 125% scaling
• Codex is maximized on the secondary display to the right of the primary display

Measured logical geometry:

Primary display:             L=0 T=0 R=1536 B=960
Secondary display:           L=1536 T=92 R=3072 B=956
Secondary working area:      L=1536 T=92 R=3072 B=908
Codex native maximized rect: L=1529 T=85 R=3079 B=915
Codex window DPI:            120, or 125%

The native maximized rect exceeds the selected monitor by 7 logical pixels on each edge. At the shared physical edge, the affected DWM frame began at X=1911 while the monitor boundary was X=1920, producing an intermittently visible rounded strip about 9 physical pixels wide on the adjacent display. Changing focus can make the strip repaint or temporarily disappear.

Additional results:

• Disabling Appearance > Translucent sidebar for both themes did not fix this specific spill.
• Restoring and maximizing can refresh the artifact but does not remove it reliably.
• View > Toggle Full Screen, or F11, works around it. In true fullscreen the DWM frame begins exactly at the physical shared edge, X=1920, and no Codex pixels appear on the adjacent display.
• Other applications on the same display layout remain within the selected monitor.

This looks like a Codex app frame clipping or native maximize bounds issue rather than a Windows monitor alignment problem.

Adding another affected environment — still reproducible on the current Microsoft Store build.

Environment

• Codex package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0 (window process: app\ChatGPT.exe)
• OS: Windows 11 Pro, version 10.0.26200, 64-bit
• GPU: NVIDIA GeForce RTX 4060 Ti (driver 32.0.16.1074) + AMD Radeon integrated graphics
• Displays (extended mode, mixed DPI):
• Primary: 3840×2160 physical @ 150% scaling (2560×1440 logical), origin 0,0
• Secondary: 2560×1440 @ 100% scaling, physical origin x=3840, directly to the right of the primary

Observed behavior

Maximizing the Codex window on either monitor makes it spill onto the adjacent monitor: a thin visible strip of the window renders on the neighboring display at the shared edge instead of being clipped to the target monitor.

Measured Win32 geometry (window maximized on the primary display)

GetDpiForWindow(hwnd) = 144. GetWindowRect observed from a DPI-unaware (96-DPI virtualized) context:

window rect:            L=-7  T=-7  R=2568  B=1400   (2575×1407 logical)
primary monitor bounds: 0,0 → 2560,1440  (work area height 1392)

The maximized window extends ~7–8 logical px (~11–12 physical px at 150%) beyond every edge of the target monitor. For ordinary maximized windows this overhang is the invisible resize border and DWM clips it on adjacent monitors; for the Codex window the strip is actually rendered on the neighboring display.

Additional data point

Forcing the process to system-DPI awareness via the AppCompatFlags\Layers → HIGHDPIAWARE shim on ChatGPT.exe / Codex.exe does not change the behavior. This is consistent with earlier comments here that the bug does not depend on mixed/high DPI scaling — it looks like the app's own frameless-window maximize geometry is not being clipped to the target monitor.

Still reproducible on 26.727.6591.0 at 100% DPI, with both adjacent-monitor and taskbar-side spill.

Environment

• Codex Microsoft Store/MSIX package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Windows 11 x64, 10.0.26200
• Codex window DPI: 96 (100%)
• Primary display: 0,0 → 2560,1440; working area: 0,0 → 2560,1392
• Windows taskbar: bottom edge, 0,1392 → 2560,1440 (48px)
• Adjacent display: directly to the right, beginning at x=2560 (1920×1080; top aligned at y=360)

Measured while Codex is natively maximized

• IsZoomed(hwnd) = true; GetWindowPlacement.showCmd = 3
• GetWindowRect = -8,-8,2568,1400
• DWMWA_EXTENDED_FRAME_BOUNDS = -8,-8,2568,1400
• Client surface in screen coordinates: -1,-1,2561,1393
• Monitor working area: 0,0,2560,1392

The DWM-visible frame therefore extends 8px past the right working-area edge into the adjacent display and 8px past the bottom working-area edge into the taskbar-reserved region. The client surface itself also crosses the right and bottom working-area boundaries by 1px. Three consecutive samples returned the same geometry.

Same-machine control

A maximized Chrome window on the same monitor at the same DPI reports the same ordinary Win32 outer rect (-8,-8,2568,1400), but its DWM visible frame and client surface are both correctly clipped to 0,0,2560,1392.

This distinguishes the Codex symptom from the normal invisible Win32 resize-border overhang. It confirms the visible/composited-frame clipping boundary, but does not establish the internal implementation root cause.

No screenshot or raw logs are attached, to avoid exposing local conversation or session information.

Disclosure: this reproduction summary was prepared and posted by Codex at the account owner's request. The account owner did not manually write or post this comment.

Adding another affected current Windows environment. This is still reproducible on the latest Microsoft Store/MSIX build available on this machine, with a mixed-DPI layout where the maximized display is physically to the left of the adjacent display.

Environment

• Codex package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Window process: app\ChatGPT.exe, product/file version 150.0.7871.182
• OS: Windows 11 Pro 24H2, build 26100.6584, x64
• GPU: NVIDIA GeForce RTX 4060, driver 32.0.15.7652 (Parsec Virtual Display Adapter also installed)
• Displays in extended mode:
• Primary / target: 3840×2160 physical, 200% scaling (192 DPI), origin 0,0, work area 0,0 → 3840,2064
• Secondary: 1920×1080, 100% scaling (96 DPI), origin 3840,313, directly to the right of the primary

Observed
When Codex is natively maximized on the primary display, part of its left sidebar/frame is visibly rendered along the left edge of the secondary display. Restoring the window removes the spill. The user reports this has persisted across versions for a substantial period.

Measured while maximized

• GetWindowPlacement.showCmd = 3
• DPI-virtualized GetWindowRect = -7,-7,1926,1038
• Physical DWMWA_EXTENDED_FRAME_BOUNDS = -13,-13,3853,2077
• Physical client surface = -1,-1,3841,2065
• Target display right boundary = x=3840

The DWM-visible frame therefore extends 13 physical pixels onto the adjacent display, and the client surface itself crosses the shared boundary by 1 pixel. This is another confirmation that the visible/composited Codex frame is not being clipped to the selected monitor during native maximize. A user-provided screenshot visually confirms the strip; it was not uploaded here because the cropped sidebar still contains local thread/project names.

Disclosure: these diagnostics and this comment were prepared and posted by Codex at the account owner's request.

I can reproduce this issue on the current Windows desktop package, and on my system it also has a significant performance impact.

Environment:

• AppX package: OpenAI.Codex 26.820.7780.0
• OS: Windows 11 Pro 25H2, build 26200.9168, x64
• Laptop: Lenovo ThinkBook 16p G5 IRX, type 21N5
• Internal display: 3200 × 2000, 200% scaling, 60 Hz
• External AOC display: 3840 × 2160, 150% scaling, 60 Hz
• Internal display owner: Intel(R) UHD Graphics, driver 32.0.101.6881
• External display owner: NVIDIA GeForce RTX 4060 Laptop GPU, driver 32.0.15.9597

The issue occurs in both directions: maximizing the app on either display causes a narrow portion of the window to appear on the adjacent display.

This is a mixed-DPI and genuine hybrid/multi-adapter display configuration. The two physical monitors are directly attached to different GPUs.

When the app leaks onto both displays, I observe severe mouse lag, delayed click feedback, sluggish UI rendering and increased desktop-composition workload. During an earlier local diagnostic session, DWM was observed using both Intel and NVIDIA GPU engines while the ChatGPT/Codex window was visible. Minimizing the window reduced measured DWM GPU utilization from approximately 24% to approximately 0%.

I have not yet used GPUView or PresentMon to prove that cross-adapter composition is the root cause, so I am reporting that part as an observed correlation rather than a confirmed diagnosis.

This appears closely related to mixed-DPI issue #37918, but the separate GPU display paths make the performance consequences much more severe on this machine.