macOs: Lag/delay in clearing terminal

[stevebakh]

Issue Description

When using command+k to clear the current tab, very occasionally, the cursor and prompt jumps back to the top, as expected, but the content remains on the display for a short time (perhaps 1-2 seconds) until the command key is released before the pane is redrawn and the content disappears.

On a Macbook Pro
16-inch, Nov 2023
Mac OS Tahoe 26.3
Apple M3 Max
64 GB

I've seen this periodically over the last month or so, but don't recall seeing it at the back end of 2025.

This can happen even on a fresh terminal with very little scrollback. I often find myself clearing the terminal very often, which is why I've seen this a few times now.

Expected Behavior

The tab is redrawn immediately and the old content disappears immediately.

Actual Behavior

The correct behaviour is seen 99% of the time. Occasionally, the content remains until the command key is released.

Reproduction Steps

1. Open ghostty
2. Run commands, do stuff that fills the terminal
3. Press command+k to clear the terminal (keep command key pressed even after releasing the k)

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+613259756

                                                                                                                                      Version                                                                                                                                                             - version: 1.3.0-main+613259756                                                                                                                                   - channel: tip                                                                                                                                                  Build Config                                                                                                                                                        - Zig version   : 0.15.2
  - build mode    : .ReleaseFast                                                                                                                                    - app runtime   : .none
  - font engine   : .coretext                                                                                                                                       - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

MacOS Tahoe 26.3

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# Auto update based on the nightly builds
auto-update-channel = tip 

# Functional settings
copy-on-select = clipboard
quit-after-last-window-closed = true
keybind = shift+enter=text:\n
desktop-notifications = true

# Fix for alt+backspace behaviour not working in Claude Code
macos-option-as-alt = true

# Appearance
font-feature = -calt
background-opacity = 0.9
background-blur = true
window-height = 35
window-width = 160
window-padding-x = 10,10
window-padding-y = 10,10
window-decoration = auto

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.

[stevebakh]

I have just witnessed the behaviour again. I already had a Ghostty terminal open on one virtual desktop. I opened a new Ghostty window. Oh-my-zsh updated, then I cleared the terminal with command+k, but kept the command key pressed and although the prompt reset and jumped back to the top, the rest of the content remained until I depressed the command key. I'm unable to reproduce this on command, unfortunately.

[mitchellh]

This almost maybe possibly sounds like a dirty tracking issue...

We may be able to reproduce this if you can record an asciinema of this happening.

[luisdavim]

BTW I've noticed that since about 1 or 2 days ago, if I use the trackpad on macbook to scroll really fast up and down on a neovim vertical split the text becomes all jumbled until the scroll stops, then it recovers, it also seems like some dirty tracking issue. It doesn’t happen when doing the same without the split.

I'll try to reproduce on a smaller screen and provide a recording but at least on a large 4k monitor it happens consistently. Using exactly the same setup kitty has no issues.

[stevebakh]

I finally managed to trigger this again while asciinema was running, and you're going to love this; I can reproduce this behaviour repeatedly now by playing back the recording and then trying to press command+k after it finishes playback, which must mean it's specific to something about the output here. Interestingly, just cat'ing out the .cast doesn't produce the same result. 🤔

I'll attach the asciinema and a screen recording (during which I used my mouse while keeping the command key pressed, which also seemed to cause a redraw):

ghostty-ghost-text.cast.zip

ghostty-ghosting.mov

[stevebakh]

Even better, I can repeatedly trigger this behaviour just by running brew info gh or any package (I just tried with brew info ghostty too).

Another data point if it's useful:

• I can't reproduce this behaviour if I full-screen ghostty.
• This happens even with opacity set to 1 and blur set to false (in fact, I tried commenting out all of my custom config settings, reloaded the config and I could still reproduce it)

[stevebakh]

Were either of you able to replicate the behaviour I'm seeing by running a brew info <package> command and hitting command+k?

[stevebakh]

This problem still occurs even with the latest tip build, and is easily repeatable/reproducible.

Another interesting point, this behaviour occurs with cmd+k but doesn't happen if I use ctrl+L, so I'm guessing these are two completely different features? Even the cursor behaviour is different between these two things and I don't see ctrl+L configured in ghostty's keybindings. 🙈

[mitchellh]

Sorry haven't had a chance yet, I did download the cast though.

And yes ctrl+l and cmd+k are different. The former emits a control sequence that the running terminal program handles (and can ignore and do nothing). The latter is handled completely in the terminal and the running program has no control.

[annacrombie]

I'm able to reproduce this reliably. If the cursor is far enough down the screen, cmd+k only clears the first few lines, then the rest are cleared when cmd is released. Just recorded a video and asciicast on f65fb3d debug-slow (but this is present on 1.3.1).

https://asciinema.org/a/901609

cast.webm