Maximized Codex window bleeds onto adjacent monitors in a multi-monitor setup

When the Codex desktop window is maximized on my primary monitor, a thin
sliver of the window (roughly 7 to 8 pixels) extends past the left and right
edges of that monitor and renders onto the two adjacent monitors. The window
content paints into the standard Windows maximize overscan region instead of
being clipped to the monitor’s work area.

Expected behavior

When maximized, the window should fill the primary monitor exactly and remain
fully contained within its bounds. No part of the window should be visible on
neighboring monitors.

Actual behavior

A narrow vertical strip of the window appears on the monitor to the left and
the monitor to the right of the primary display. The bleed occurs on the left
and right edges only.

Steps to reproduce

  1. Use a multi-monitor setup where monitors sit flush against the left and
    right edges of the primary monitor.
  2. Move the Codex window to the primary monitor.
  3. Maximize the window.
  4. Observe the left and right edges spilling onto the adjacent monitors.

Why this appears to happen

When Windows maximizes a window, it extends the window rectangle by about 7 to
8 pixels on every side. Those extra pixels are the invisible resize border, and
on a single monitor they fall harmlessly off the screen edge. Apps that use a
native non-client frame leave that region empty, so nothing shows. Codex draws
its custom titlebar and content edge to edge, so it paints into the overscan
region, and on a multi-monitor layout the left and right slivers land on the
neighboring displays instead of falling off-screen.

 Main monitor edge ─┐                           β”Œβ”€ Main monitor edge
                    β–Ό                           β–Ό
 β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”
 β”‚  LEFT   β”‚β–‘β–‘β”‚            CODEX (maximized)       β”‚β–‘β–‘β”‚  RIGHT  β”‚
 β”‚ monitor β”‚β–‘β–‘β”‚                                    β”‚β–‘β–‘β”‚ monitor β”‚
 β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
            β–²                                        β–²
            └─ ~8px overscan bleeds onto neighbor β”€β”€β”€β”˜

A common fix is to clamp the maximized bounds to the monitor work area, or to
account for the maximize offset when laying out the window content.

Environment

Operating system

Property Value
Edition Windows 11 Home
Version 25H2
Build 10.0.26200.8457

Graphics

  • NVIDIA GeForce RTX 5080
  • Intel Graphics (integrated)

Monitor layout

All three monitors run at 100 percent display scaling, so a per-monitor scaling
mismatch is not a factor.

Role Device Resolution Orientation Scale Position (X, Y)
Primary (maximized here) DISPLAY1 2560 Γ— 1440 @120Hz Landscape 100% (0, 0)
Left DISPLAY3 1920 Γ— 1080 Landscape 100% (βˆ’1920, 278)
Right DISPLAY2 1080 Γ— 1920 Portrait 100% (2560, βˆ’80)

The left monitor’s right edge meets the primary monitor at x = 0, and the right
monitor’s left edge meets the primary monitor at x = 2560. Because both
neighbors sit directly against the primary monitor’s edges, the maximize
overscan slivers render onto them rather than falling off-screen.

Notes

  • The bleed is purely visual; the window otherwise functions normally.
  • Reproduces consistently on every maximize.
  • A screenshot showing the slivers can be provided on request.
1 Like