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

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?

Use Codex Desktop on Windows with a multi-monitor setup.
Place the Codex window on the center monitor.
Maximize the Codex window.
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:

Codex Desktop on Windows: rendering freezes/transparency when maximized #25513: Codex Desktop on Windows: rendering freezes/transparency when maximized
Windows: maximized Codex window shows transparent/desktop bleed-through after 26.527.3686.0 update #25217: Windows: maximized Codex window shows transparent/desktop bleed-through after 26.527.3686.0 update
Windows Codex app header and left sidebar become transparent when maximized #25347: Windows Codex app header and left sidebar become transparent when maximized
Codex App: sidebar and top menu become transparent when maximized on Windows #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.

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.

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, build 12776, production release channel. The app's update check reported up_to_date after 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 + Up reproduces 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

@bc-openai Can you reopen this? V26.930.21537 doesn't fix it. Thank you!

@etraut-openai

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

Still not fixed... latest build.

I'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/2108635479843242414

Still 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!

@chess-oai

@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?

Confirming that the adjacent-monitor spillover is resolved on my Windows multi-monitor setup as of October 15, 2026. Maximizing Codex no longer leaves a visible strip or border on the neighboring monitors.

Current Microsoft Store package: OpenAI.Codex_26.1007.9446.0_x64__2p2nqsd0c76g0 (package version 26.1007.9446.0).

I do not know exactly which update resolved it on my machine; I noticed the improvement within the last few days and can confirm it is fixed today. Thanks for the fix!

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

41 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

MtkN1 commented on Jun 12, 2026

today080221 commented on Jun 16, 2026

kevinzien1107-ctrl commented on Jun 24, 2026

BoillingFish commented on Jul 8, 2026

UPSOKen commented on Jul 11, 2026

gilmarvitor commented on Jul 16, 2026

gaocapital commented on Jul 27, 2026

zhiwenliang commented on Aug 1, 2026

enderdantelian-lab commented on Aug 3, 2026

HailiangLoo commented on Aug 4, 2026

41 remaining items

wbdb commented on Oct 1, 2026

goro0803-droid commented on Oct 2, 2026

wbdb commented on Oct 2, 2026

wbdb commented on Oct 5, 2026

chess-oai commented on Oct 5, 2026

coolfarmer commented on Oct 8, 2026

jim608 commented on Oct 8, 2026

wbdb commented on Oct 9, 2026

AMArostegui commented on Oct 9, 2026

chess-oai commented on Oct 9, 2026

wbdb commented on Oct 9, 2026

Ali229 commented on Oct 9, 2026

MtkN1 commented on Oct 10, 2026

claell commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions