Repository navigation
Windows Desktop: maximized window spills onto adjacent monitors in multi-monitor setup #25826
Description
Activity
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.
Reacted by Claudius Ellsel, Chris Conkright, wbdb, Scott Arbeit, Hugo, Pavel Kocian, Brian Garon and KoaOkanoAdding 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.
Reacted by Scott ArbeitI 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}
- Primary:
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 are0..1707horizontally. - 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.
- Codex package:
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, build26200, 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.
- Codex Windows app package:
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.
Reacted by Scott ArbeitConfirming 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=1911while the monitor boundary wasX=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.
Reacted by Scott Arbeit and Hugo- Codex package:
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
- Primary: 3840×2160 physical @ 150% scaling (2560×1440 logical), origin
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.GetWindowRectobserved 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→HIGHDPIAWAREshim onChatGPT.exe/Codex.exedoes 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.- Codex package:
Still reproducible on
26.727.6591.0at 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 aty=360)
Measured while Codex is natively maximized
IsZoomed(hwnd) = true;GetWindowPlacement.showCmd = 3GetWindowRect = -8,-8,2568,1400DWMWA_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 to0,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.
- Codex Microsoft Store/MSIX package:
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 version150.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 area0,0 → 3840,2064 - Secondary: 1920×1080, 100% scaling (96 DPI), origin
3840,313, directly to the right of the primary
- Primary / target: 3840×2160 physical, 200% scaling (192 DPI), origin
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.
- Codex package:
- marked 🩹 Codex Windows app maximized window leaks thin strip onto adjacent monitor #26168 as a duplicate of this issue
on Aug 6, 2026 - marked Codex App window leaks a thin edge onto the adjacent monitor in dual-screen setup #30448 as a duplicate of this issue
on Aug 6, 2026 40 remaining items
Version 26.928.21956, still happening. Three monitors, one 2560x1600 and two 4k; all at 150% OS scaling.
Same issue with version 26.928.31416
Additional user confirmation on October 3, 2026 (Asia/Tokyo): the visible spillover still reproduces on Codex desktop version
26.930.21537, build12776, production release channel. The app's update check reportedup_to_dateafter the user restarted the app.Environment and observed behavior:
- Windows desktop with two monitors. Exact OS build, GPU, and display scaling have not been collected.
- Maximizing Codex leaves a thin white strip, a few pixels wide, visible at the shared edge on the adjacent monitor.
- The user supplied screenshots in a private conversation showing the strip along the right edge of the neighboring desktop.
- The user reports this happens only with Codex, not other applications.
- Maximizing with
Win + Upreproduces the same issue as the maximize button. - Updating and restarting did not resolve it.
Expected: all visible parts of a maximized Codex window should remain inside the selected monitor's work area.
Please consider reopening this issue, or directing this confirmation to the active tracking issue. Screenshots are not attached here because the full app screenshot includes unrelated chat and project names.
This comment was prepared and submitted by Codex at the user's explicit request.
@bc-openai Can you reopen this? V26.930.21537 doesn't fix it. Thank you!
Reacted by SamuelHaleMN, Joshua Filby, GhostTyper, HailiangLoo, Muhammad Ali, extisher001, noelwehrle-at-mehrsalz and th2646@etraut-openai @chess-oai Version 26.930.41038 doesn't fix it. The error has persisted since June 2. It has not been resolved. Please reopen this case.
apologies gang, we've got one more fix en route. reopening until it lands.
Reacted by wbdbStill not fixed... latest build.
Reacted by GhostTyperI've also encountered this problem.
With every new update, you get your hopes up... and then...
But just so you don't get too comfortable on the web: https://x.com/dboedger/status/2108635479843242414Still happening in 26.1002.52244
thanks for sticking with us, and apologies this has been such a journey. fingers crossed our final fix is included in 26.1007.21434 (store package 26.1007.2314.0). please update and report back!
Reacted by th2646, KoaOkano, Joshua Filby and Kent Matsuura@chess-oai Fixed 🎉🎉🎉Please make sure to designate at least one person internally who can keep an eye on these kinds of issues for Windows on an ongoing basis. It was really annoying for weeks. But I'm very grateful that it's finally taken care of.
Finally it's fixed!
Thanks for the fix! Really glad this is resolved.
One thing I've noticed, though: the animation when maximizing the window seems to be gone, so it feels a bit abrupt compared to other apps. I'm not sure if this is related to the fix. Has anyone else noticed this?
Reacted by wbdb
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__2p2nqsd0c76g0What subscription do you have?
Unknown / not relevant.
What platform is your computer?
Windows 11 Education, version
10.0.26200, build26200, 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:
32.0.15.963632.0.101.8724What 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?
Observed result:
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/codexissues 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:Those reports may share the same maximize-related code path, but this issue is specifically about the maximized window visibly spilling onto adjacent monitors.