›_ Codex Issues
Codex Issues / #34023

Codex Desktop on Windows overflows screen bounds on multi-monitor 200% DPI setup

Open 💬 2 comments Opened Jul 18, 2026 by lmf-cumt

What version of the Codex App are you using?

OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0

Executable path observed locally:

C:\Program Files\WindowsApps\OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

What platform is your computer?

Windows x64

Display setup

The issue reproduces with a dual-monitor setup and 200% DPI scale reported for the Codex window.

Detected monitor layout:

DISPLAY1: secondary, Bounds X=-1536 Y=0 W=1536 H=960, WorkingArea X=-1536 Y=0 W=1536 H=912
DISPLAY2: primary,   Bounds X=0     Y=0 W=1920 H=1080, WorkingArea X=0     Y=0 W=1920 H=1032
Codex/ChatGPT window DPI: 192 (200%)

What issue are you seeing?

The Codex desktop window repeatedly exceeds the current screen bounds on Windows. The issue persists after normal recovery attempts, including rebooting, restoring from maximized state, manually resizing, using Windows snap shortcuts, and programmatically moving the window back into the primary monitor working area.

Observed Win32 window geometry while the app was maximized on the left secondary display:

Window rect:              L=-1543 T=-7 R=6 B=918 W=1549 H=925
DISPLAY1 working area:    X=-1536 Y=0 W=1536 H=912
Saved normal position:    L=-1363 T=221 R=-273 B=981 W=1090 H=760

The maximized window rect is larger than the monitor working area and extends beyond the screen edges. The restored normal position also exceeded the bottom of DISPLAY1.

Steps to reproduce

  1. Use Codex Desktop on Windows with a dual-monitor setup where the secondary display is positioned to the left of the primary display.
  2. Use 200% DPI scaling.
  3. Move Codex Desktop / ChatGPT window to the left secondary display.
  4. Maximize, restore, resize, close, and reopen the app.
  5. Observe that the window can restore or maximize outside the monitor working area.

Expected behavior

The Codex desktop window should stay within the active monitor working area when restored, resized, maximized, closed, and reopened.

Actual behavior

The window repeatedly returns to bounds outside the current monitor working area. Normal Windows recovery actions do not make the fix persist.

Workarounds tried

  • Rebooted the computer.
  • Restored the window from maximized state and manually resized it.
  • Used Win + Arrow snap shortcuts to refresh the window placement.
  • Programmatically forced the main window back into the primary screen working area:
Forced safe rect: L=80 T=80 R=1360 B=952 W=1280 H=872
Primary working area: X=0 Y=0 W=1920 H=1032

The issue still returned afterward.

Additional information

The app appears to be the Windows packaged Codex desktop app. The process name is ChatGPT, and the executable path is under OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0.

View original on GitHub ↗

2 Comments

HanChangHun · 1 month ago

Additional reproduction at 100% DPI

I can reproduce the same out-of-work-area maximized bounds on the exact package version from this issue, but at 100% DPI rather than 200% DPI.

Environment

  • Codex package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
  • Executable: packaged ChatGPT.exe
  • OS: Windows 11 Enterprise, build 10.0.26200, x64
  • Install method: Microsoft Store / MSIX
  • Main display: 1920x1080, working area 0,0,1920,1032
  • Secondary display: portrait 1080x1920
  • Codex window DPI: 96 (100%)
  • GPU: NVIDIA GeForce RTX 3060
  • Translucent sidebar: disabled for the active theme

Reproduction

  1. Launch Codex Desktop on the primary display.
  2. Maximize it with the native maximize control.
  3. Observe a dark full-width strip immediately above/into the Windows taskbar.
  4. Restore the window, then maximize it again.

Runtime evidence

The live window was selected by its top-level title ChatGPT. Bounds were captured with GetWindowRect, DwmGetWindowAttribute(DWMWA_EXTENDED_FRAME_BOUNDS), Screen.WorkingArea, and GetDpiForWindow.

| State | Window rect | DWM extended frame | Monitor work area |
|---|---|---|---|
| Maximized | -8,-8,1928,1040 | -8,-8,1928,1040 | 0,0,1920,1032 |
| Restored | -74,-15,1846,1008 | -74,-15,1846,1008 | 0,0,1920,1032 |
| Re-maximized | -8,-8,1928,1040 | -8,-8,1928,1040 | 0,0,1920,1032 |

The native maximized state therefore exposes an 8px DWM frame beyond every work-area edge, including 8px into the taskbar side. Restoring removes the bottom overflow; re-maximizing restores it exactly.

For comparison on the same primary display, a maximized Whale/Chromium window reported the same outer Win32 rect (-8,-8,1928,1040) but a correctly clipped DWM extended frame of 0,0,1920,1032. This suggests the problem is not the ordinary invisible Windows resize border by itself; Codex is exposing that border as part of its visible/composited frame.

Disabling the translucent sidebar improved the separate transparency artifact but did not change these maximized bounds. A separate avatar overlay is enabled on this machine, but its window is only about 408x400 on the secondary display; the remaining strip spans the full width of the main Codex window, and the main window's own DWM bounds reproduce the overflow.

Failure boundary and likely fix direction

The confirmed failure boundary is the packaged Windows desktop shell's native-maximize/frame-composition path. The public openai/codex tree at 0fb559f0f6e231a88ac02ea002d3ecd248e2b515 does not include the Electron desktop-shell implementation, so I cannot identify an exact public source file.

A fix should ensure that, while natively maximized, the visible/composited DWM frame is constrained to the active monitor working area even if the underlying Win32 resize-border rect remains offset by 7-8px. Suggested regression coverage:

  • 100% and 200% DPI
  • single- and multi-monitor layouts
  • monitors placed left, right, and above/below the primary display
  • opaque and translucent chrome modes
  • assert the visible DWM extended frame does not cross MONITORINFO.rcWork
CxMYu · 29 days ago

Still reproducible on 26.721.11231.0 with mixed-DPI monitors

Confirmed on a newer Codex Desktop build with a different dual-monitor layout.

Environment

  • Codex package: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
  • Executable: packaged ChatGPT.exe (Chromium Chrome_WidgetWin_1 window)
  • OS: Windows 11 Pro for Workstations, build 10.0.26200, x64
  • Primary/right display: physical bounds 0,0,3072,1920; work area 0,0,3072,1824; scale 200%
  • Secondary/left display: physical bounds -1920,0,0,1080; work area -1920,0,0,1032; scale 100%
  • Codex window DPI: 192 (200%)
  • No AppCompat high-DPI override is configured for Codex/ChatGPT

Observation

When Codex is maximized on the 200% primary display, part of its left title-bar/frame is visibly composited onto the adjacent 100% display. The visible spill is roughly the size of the DPI-scaled resize border (about 13-16 physical pixels in the captured reproduction).

This persists in 26.721.11231.0, so the newer package has not fixed the maximize/frame clipping behavior.

Control comparison

On the same machine, maximized Chrome and PyCharm windows on the 100% left display report:

  • Win32 window rect: -1928,-8,8,1040
  • DWM extended frame: -1920,0,0,1032
  • Monitor work area: -1920,0,0,1032

Those applications keep the normal 8px Win32 resize-border overhang but correctly clip the visible DWM frame to the monitor work area. This further points to the Codex desktop shell's visible frame/custom-title-bar clipping path rather than the ordinary Win32 maximize rectangle alone.