Ghostty resets window height to the max height on the monitor the window was created on

[sbirch-fl]

Issue Description

When resizing a ghostty window vertically, the window snaps back to the maximum height that it could be on the screen it was created on. By "maximum height" I mean the area of the screen that isn't covered by panels.

Note that in the log below, info(osc): unknown semantic prompts option: special_key is output while the resize drag is happening, and no output is logged when Ghostty resets the height.

Expected Behavior

The window height stays where you drag it.

Actual Behavior

After a moment, the window height is reduced to the maximum available height on the shorter monitor (where the window was created).

Reproduction Steps

1. Have two monitors, one of which has more (logical) vertical pixels than the other.
2. Open a new Ghostty window on the shorter monitor.
3. Move the window to the taller monitor.
4. Drag the window frame to make the window taller than it would be able to be on the shorter monitor.

Ghostty Logs

info: ghostty version=1.1.3-dev+0000000
info: ghostty build optimize=ReleaseFast
info: runtime=apprt.Runtime.gtk
info: font_backend=font.main.Backend.fontconfig_freetype
info: dependency harfbuzz=8.4.0
info: dependency fontconfig=21402
info: renderer=renderer.OpenGL
info: libxev backend=main.Backend.io_uring
info(os): setlocale from env result=en_US.UTF-8
info(gtk): GTK version build=4.18.4 runtime=4.18.6
info: reading configuration file path=/home/sam-birch/.config/ghostty/config
info(config): default shell source=env value=/usr/bin/fish
warning(gtk): setting GDK_DEBUG=gl-no-fractional
warning(gtk): setting GDK_DISABLE=gles-api,vulkan
Unrecognized value "gl-no-fractional". Try GDK_DEBUG=help

(process:111884): Gtk-WARNING **: 15:37:56.159: Unknown key gtk-modules in /home/sam-birch/.config/gtk-4.0/settings.ini
info(grid): loaded OpenGL 4.6
info(font_shared_grid_set): font regular: IosevkaTerm NF
info(font_shared_grid_set): font bold: IosevkaTerm NF Bold
info(font_shared_grid_set): font italic: IosevkaTerm NF Italic
info(font_shared_grid_set): font bold_italic: IosevkaTerm NF Bold Italic
info(io_exec): found Ghostty resources dir: /home/sam-birch/.local/share/ghostty
info(io_exec): shell integration automatically injected shell=termio.shell_integration.Shell.fish
warning(gtk): unimplemented action=apprt.action.Action.Key.cell_size
warning(gtk): currentTab
info(io_exec): started subcommand path=/bin/sh pid=111924
info(io_exec): subcommand cgroup=-
warning(stream): unimplemented OSC callback: terminal.osc.Command{ .end_of_command = terminal.osc.Command.Command__struct_98441{ .exit_code = null } }
warning(stream): unimplemented OSC command: end_of_command
info(grid): reallocating GPU buffer old=0 new=8
info(osc): unknown semantic prompts option: special_key
info(font_codepoint_resolver): found codepoint 0xFF1A in fallback face=Noto Sans CJK JP Regular
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key
info(osc): unknown semantic prompts option: special_key

Ghostty Version

Ghostty 1.1.3-dev+0000000

Version
  - version: 1.1.3-dev+0000000
  - channel: tip
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - desktop env: other
  - GTK version:
    build      : 4.18.4
    runtime    : 4.18.6
  - libadwaita : enabled
    build      : 1.7.2
    runtime    : 1.7.5
  - libX11     : enabled
  - libwayland : enabled

OS Version Information

Fedora 42

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

KDE Plasma 6.4.3

Minimal Ghostty Configuration

# this happens even with an empty config file

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[mitchellh]

I don't have multiple monitors to test this, but I wonder if this is a GTK issue or if we're inadvertently setting the max size anywhere.

[sbirch-fl]

I can also trigger this by reducing my screen resolution, opening a new Ghostty window, and then increasing the resolution again. Same behavior without multiple monitors.

[Kayzels]

I don't think it's a GTK issue. At least, other GTK apps (such as Lutris) seem to be able to resize correctly.

It seems that it's determining the dimensions based on whichever screen it is opened on, and will never get larger than that. It can be resized to smaller, but it's like it clamps the size. It's not just with regards to height, but width as well. Opening Ghostty on a 1366x768 screen means that's the largest it can get, even when moved to a 1080p screen. I tried to check in the inspector, but there was nothing obvious that would suggest why this happens. I imagine it's something very tricky (probably impossible) to check without having two monitors of different sizes.

[digitalsignalperson]

I was gonna open a bug but found this discussion and #5569 and #4869

Seems like a bug but there's three existing discussions, so I'm not sure what the rules want me to do. So just posting my report here instead of submitting a new issue.

Description

• fresh install of ghostty, no config
• arch linux, wayland kde plasma desktop
• If I open ghostty on my primary monitor (2560x1600) and then drag the window over to my 4k screen, if I resize the window big enough, it will hold the size for a moment before snapping back down to the max size that would fit in 2560x1600
• However if I start ghostty with mouse focused on the 4k screen, it launches on the 4k screen and does not have this auto-resize issue.

Expected behavior
I should be able to resize the window to any dimension, even bigger than the resolution of the screen the application was launched on.

Actual behavior:
If you resize the window bigger than the monitor resolution on which it was launched, it will auto resize to have max width and max height per the specific monitor resolution, even when resizing on e.g. a secondary 4k screen, when the program started on the 2k screen.

Exceptions:

• Maximizing the window works
• Using Super+{Left,Right} to tile to half the screen prevents the auto resize-down

Reproduction steps

1. Kde plasma wayland with two monitors, the primary monitor having a lower resolution than the 2nd
2. Open ghostty with mouse focused on the smaller monitor
3. Drag the window over to the bigger monitor
4. Resize the window with the mouse (click and drag the window border, or use Super+Rightclick and drag)
5. After resizing the window to be taller or wider than the primary monitor, observe whether the window maintains its size

Repeat the same but start ghostty with mouse focused on the bigger monitor.

Ghostty logs
I see these spammed for every key event and while resizing the window (seems unrelated)

warning(gtk_ghostty_surface): gtk-xft-dpi was not set, using default value
info(osc): unknown semantic prompts option: click_events

Ghostty version
Ghostty 1.2.0-arch1

Version

• version: 1.2.0-arch1
• channel: tip
  Build Config
• Zig version : 0.14.1
• build mode : builtin.OptimizeMode.ReleaseFast
• app runtime : apprt.Runtime.gtk
• font engine : font.main.Backend.fontconfig_freetype
• renderer : renderer.generic.Renderer(renderer.OpenGL)
• libxev : io_uring
• kernel version: 6.16.8-arch3-1
• desktop env : other
• GTK version :
  build : 4.18.6
  runtime : 4.20.2
• libadwaita : enabled
  build : 1.7.7
  runtime : 1.8.0
• libX11 : enabled
• libwayland : enabled

OS/Display server/WM
Arch linux
Wayland
KDE Plasma 6.4.5

Minimal ghostty config
none, defaults only

[moskrin]

I've just had this issue as well. Debian 13, Ghostty 1.2.1-1.trixie, KDE Plasma 6.3.6 on Wayland. Moving the window from my laptop screen at 1920x1200 to my external 4k monitor, if I drag the window larger it just snaps back to its previous size.

If I keep the window on my laptop and drag it up and left so it's partially off-screen, then resize it so it's larger than the laptop screen, it will also snap back to its orginal size, so the external monitor part doesn't seem critical to reproduction.

[alaestor]

Ah... That explains it. Thanks.

I've always had an issue where Ghostty's width would snap back to some maximum after resizing. I usually launch Ghostty via a taskbar pin on my right-most monitor, which is 1080p in portrait orientation (I'm on KDE6 NixOS). I just tried launching Ghostty from krunner on my main 4K landscape monitor and it's maintaining its width properly.

The options say "sizes larger than the screen size will be clamped to the screen size"; I thought that only applied to the initial size but maybe not? And clearly it (or something) determines screen size at launch and doesn't seem to re-evaluate it when moving between monitors.

[arusahni]

Similar issues as others here (KDE Plasma), with the added nuance that Ghostty launched on my laptop display (lower resolution), which I then connected to a higher-resolution display and shut, making the external monitor the only screen. I had to restart Ghostty in order to use all the pixels available to me.

[maudrid]

I'm using X11 and Cinnamon and have similar behavior. Except when I drag the window larger than 255 text columns, the height of the window snaps to zero even before I release the mouse.

[yak3d]

I'm on KDE Plasma + Wayland and also observe this. I have one display at 2560x1440, and another at 1440x2560. The window always reverts back to dimensions that would fit the 2560x1440.

If you maximize the window though, it does work fine.

2026-03-26_21-51-15.mp4