Wayland tiled window reports 600px viewport while allocated 508px

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

26.814.41957-1 (openai-codex-desktop; Electron 42.3.0)

What subscription do you have?

Plus

What platform is your computer?

Linux 7.1.9-arch1-2 x86_64 unknown; Hyprland 0.56.2; native Wayland

What issue are you seeing?

When tiled below the app's hard-coded minimum height, the Codex App does not use the compositor-assigned height internally.

Independently verified on native Wayland:

• Hyprland allocated the window at 941×508 logical px.
• The renderer simultaneously reported window.innerWidth × window.innerHeight = 941×600.
• document.documentElement.clientHeight, document.body.clientHeight, and visualViewport.height were also 600.
• The result is a 92 px bottom overflow/crop while the compositor continues to report a 508 px tiled surface.

The installed package hard-codes getPrimaryMinimumSize() as { width: 480, height: 600 }. Its minimum-size synchronization calls both setMinimumSize(480, 600) and a follow-up setBounds(...) clamp. A floating 941×508 window was forcibly resized to 941×600 after one second.

On this Hyprland version, the outer window remained tiled at 941×508; the renderer still used 600 px.

Launch behavior: the window initially appears at the compositor-assigned tiled size and looks correct. After initialization/minimum-size synchronization, the renderer grows to its 600 px internal height while the compositor surface remains 508 px, so the bottom of the UI is clipped/out of bounds.

What steps can reproduce the bug?

1. Run Codex App 26.814.41957-1 on a native Wayland Hyprland session.
2. Tile the app to a 941×508 logical-pixel region (for example, a quarter of a 1920×1080 work area).
3. Observe the loading window and wait for the app's minimum-size synchronization.
4. Inspect the compositor: hyprctl clients -j reports the app at 941×508.
5. Inspect the renderer via Chromium remote debugging: innerHeight, document.documentElement.clientHeight, document.body.clientHeight, and visualViewport.height report 600.

Control: when floated and set to 941×508, the app changed itself to 941×600 after roughly one second.

What is the expected behavior?

The renderer viewport must match the compositor-assigned tiled size (941×508 in this case) so content reflows or scrolls instead of being clipped. If a minimum is needed, declare it with BrowserWindow.setMinimumSize() without subsequently forcing setBounds() to a larger size. A tiled window must not resize itself or render beyond its allocated surface.

Additional information

Hyprland setting: misc:size_limits_tiled = false, so the compositor intentionally permits a tiled client below its advertised minimum. This app should handle that allocation correctly.

Happy to provide more diagnostics (screenshots, logs, exact compositor dumps) if required.

Generated with GPT 5.6 Terra and diagnosed by Sol and myself.