X11: Bash cursor moves inside a soft-wrapped prompt after resize with shell integration disabled

[toppk]

Issue Description

On Ghostty 1.3.1 using the GTK X11 backend, shrinking a window until the current Bash prompt soft-wraps and then widening it again can leave the cursor inside the prompt instead of after it.

The same test does not reproduce for me with Ghostty's native Wayland backend.

This reproducer explicitly disables Ghostty shell integration. Related reports such as #1961, #209, and #2214 are not exact duplicates, but they are useful context: they are why I made sure this case can be reproduced without shell integration or a multiline/dynamic prompt.

Expected Behavior

After the window is widened again, the prompt should appear once and the cursor should remain immediately after the trailing space.

Actual Behavior

After the narrow-to-wide resize, the cursor lands partway through the prompt. Repeating the resize can leave additional corrupted or duplicated prompt fragments.

Reproduction Steps

1. From a Wayland GNOME session, start Ghostty forced onto X11 with this exact command:

   PS1="someitnh rellayl logn so you can see" GDK_BACKEND=x11 ghostty --shell-integration=none -e bash --noprofile

2. Begin with the window wide enough for the prompt to fit on one row.

3. Drag the window narrower until the prompt wraps.

4. Widen the window again.

5. Observe that the cursor is now inside the prompt rather than at its end.

For an even more isolated Bash environment, --norc can be added, but it is not required for the reproduction.

Running the equivalent command without GDK_BACKEND=x11 under the native Wayland backend does not reproduce the problem for me.

Ghostty Logs

I did not observe a relevant warning or error in the log. The failure is visible as incorrect terminal state after the resize rather than as a crash.

Ghostty Version

Ghostty 1.3.1 (stable)
Zig 0.15.2
ReleaseFast
GTK runtime
fontconfig_freetype
OpenGL renderer
libxev epoll
GTK 4.22.4

OS Version Information

Fedora Linux 44 Server Edition
Linux 7.1.5-201.fc44.x86_64
Bash 5.3.9

(Linux only) Display Server

The desktop session is Wayland. The failing Ghostty instance is explicitly run with GDK_BACKEND=x11. The same reproduction does not fail when Ghostty uses its native Wayland backend.

(Linux only) Desktop Environment/Window Manager

GNOME Shell 50.4

Minimal Ghostty Configuration

No configuration is required. Shell integration is disabled on the command line:

--shell-integration=none

Additional Relevant Configuration

Tentative explanation, not a confirmed diagnosis: Ghostty's terminal I/O thread coalesces resize notifications, while GTK's X11 and Wayland backends can deliver different allocation/configure sequences. On X11, an intermediate narrow size may be committed to the terminal and PTY: Ghostty reflows the existing prompt, Bash receives SIGWINCH and redraws it, and the resulting state combines the reflowed prompt with the redraw. The Wayland event sequence may replace or suppress that intermediate size before it is committed. The shared terminal reflow logic appears to make backend event timing/cadence a more likely source of the difference than separate X11 and Wayland reflow implementations.

AI Assistance Disclosure

This report was prepared with assistance from OpenAI Codex. I developed and manually verified the reproducer and the X11/Wayland behavior. Codex helped inspect Ghostty's resize path, locate related reports, formulate the tentative explanation, and edit the report. I reviewed the related reports and edited the final framing to explain why the shell-integration-free reproducer matters before submission.

Acknowledgements

• I have reviewed the FAQ and confirm that my issue is not covered there.
• I have searched open and closed Ghostty Discussions and Issues and do not believe this is a duplicate.
• I have reviewed the rendered Markdown and code blocks.

[ChangkeunJ]

I'd bet this isn't really a backend difference, and that X11 just hands you more chances to hit it.

Bash redraws on SIGWINCH through readline, and readline tracks the cursor itself rather than asking the terminal where it is. Ghostty rewraps soft-wrapped text on resize by default, Screen.ResizeOptions has reflow: bool = true, and it does fix up its own cursor through the reflow. So after the narrow-to-wide drag the terminal's cursor is where it should be, but readline still believes the prompt is sitting on the second row of a wrapped line, and its redraw moves the real cursor back to match that stale belief. That's your cursor landing partway through the prompt, and the duplicated fragments on repeated resizes are the same error compounding on itself.

Shell integration papers over this precisely because it hands ghostty prompt marks, so the terminal knows where the prompt begins and can put things back. You turned it off deliberately, which is the right instinct for isolating a bug, but it also removes the only channel either side has for agreeing on where the prompt is.

X11 vs Wayland then falls out of how many SIGWINCHs land during the drag rather than anything about what got committed to the pty. GTK's X11 backend fires configure events continuously while you're dragging, Wayland typically gives you far fewer intermediate sizes. More redraws at more widths, more chances for readline to be holding the wrong number when you let go.

There's a cheap way to decide this before anyone goes digging through the resize path. Run the identical reproducer under zsh:

PS1="someitnh rellayl logn so you can see" GDK_BACKEND=x11 ghostty --shell-integration=none -e zsh -f

zle redraws on SIGWINCH quite differently from readline. If zsh stays clean through the same drag, the reflow contract is fine and this is readline's bookkeeping, which would make it a wontfix here and a known bash quirk everywhere. If zsh corrupts too, then your intermediate-size theory is worth chasing and it's genuinely a ghostty bug. Two minutes either way and it tells you which half to look at.

[toppk]

Thanks for looking at this. I did verify that this didn't happen with zsh, which might have sent me down a correct path sooner. But in any case, it seems like bash/readline has already discovered this issue, just hasn't hit my distro yet. https://lists.gnu.org/archive/html/bug-bash/2026-05/msg00065.html

I consider your answer sufficient, but i'm leaving this note here for anyone who's actually looking for the fix.