Performance degradation over time + accelerated repro

[bearcage]

Issue Description

tl;dr unfocus/focus ghostty in a loop, watch send-rights climb on one port in lsmp

I noticed a significant gradual performance decline on an M3 max macbook with ghostty, safari, discord, and activity monitor and nothing else open. This first happened after not exiting ghostty for quite some time while doing ordinary work, so I started fishing for reasons why it might be slowing down.

I also had a decent chunk of cpu time on the system spent in WindowServer (in compositing tasks, per sample output), which cleared up on a reboot, so initialy I figured maybe unrelated, maybe red herring, maybe I just got unlucky, but it turns out actually this might be related.

Trying to see if I could reproduce the ghostty slowdown, I tried to think of things that I do in regular use which might provoke state changes — connecting and disconnecting external displays, sleeping and waking, alt-tabbing, copying/pasting, etc. I figured some of those I can artificially speed up, so I started with the easiest of those, alt-tabbing, and hit on something that looks legit. If you use applescript to slam unfocus/focus in a hot loop, you can pretty quickly reproduce the state I got in to.

The only thing I was able to dig up poking at the process which pointed to resource exhaustion or leaking (I'm not exactly a macOS expert, linux is my day job) was what looks like an ever-growing number of send-rights on one mach port in lsmp for ghostty.

Expected Behavior

Ideally not slow down

Actual Behavior

The whole system gets slow after a while of this abuse, in a way that doesn't seem to happen when doing the same to Safari or Apple's Terminal.app

Reproduction Steps

1. Open Ghostty
2. Open another terminal emulator and use it to run osascript -e 'repeat 4000 times' -e 'tell application "Finder" to activate' -e 'tell application "Ghostty" to activate' -e 'end repeat'
3. Do that a few more times (or pick a bigger repeat number)

As you go along, watch WindowServer's CPU load, and notice the frequency of flicker in window decoration focus display getting more uneven over time. Also note the system getting a little less predictably-instant doing things like switching focus to other applications (in between runs above, of course).

After a couple rounds of this, I'm able to get WindowServer's cpu load up to the mid-60% (with nothing going in ghostty, just a shell waiting for input). When you quit ghostty, WindowServer's cpu load will drop, but not to a normal idle-system level (mine in my latest run of these steps went from 68% to ~25%, and back up to 30% when I reopened ghostty to idle it).

Ghostty Logs

Timestamp                       Thread     Type        Activity             PID    TTL  
2026-03-24 01:29:45.853087-0700 0x194c     Debug       0x0                  664    0    ghostty: [com.mitchellh.ghostty:SecureInput] secure input state=true
2026-03-24 01:29:48.868001-0700 0x194c     Debug       0x0                  664    0    ghostty: [com.mitchellh.ghostty:SecureInput] secure input state=false
2026-03-24 01:29:48.972259-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:29:54.789598-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:30:50.527398-0700 0x4527b    Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:ghostty] Error while requesting notification authorization: Error Domain=UNErrorDomain Code=1 UserInfo={NSLocalizedDescription=<private>}
2026-03-24 01:32:39.764589-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:32:41.986640-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:32:52.538367-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:05.598772-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:10.156175-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:10.950137-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:15.801723-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:42.993950-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:43.374403-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local
2026-03-24 01:33:43.609587-0700 0x1e40     Error       0x0                  664    0    ghostty: [com.mitchellh.ghostty:io_handler] io_handler: OSC 7 host (zeal.local) must be local

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
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.1 (a)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

N/A — I only have a theme and shell-integration-features=ssh-env, neither of which should be related.a

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.

EDIT: deleted redundancy — turns out typing on a machine that's slowed to a crawl is a bit of a struggle.

[mitchellh]

I haven't tried to reproduce this yet, but I appreciate the detailed response. Can I ask: do you have secure input enabled (within Ghostty, via the menu item in "Ghostty")?

The fact this continues after quitting really smells like a macOS bug, but I'm interested in understand how we trigger that of course and how we can mitigate it.

I'll try your repro soon!

[bearcage]

Thanks for following up! I don't have the menu item enabled (though I do have the little secure-input overlay icon on password entry for e.g. sudo).

Another potentially interesting datapoint, the amount of cpu time spent in WindowServer once it's in this state seems (I don't have a lot of test runs or many monitors to test with) proportionally higher when connected to high refresh rate external displays. Concretely, I use a pair of 4k 240Hz displays when I'm at my desk, and connecting the macbook to them after provoking this state aggravates it to the tune of 10-15% of a core.

[bearcage]

I wonder if #13090 is pointing in the right direction — "gets slower when there's more IOSurfaces in existence" sounds like behavior I'd expect of WindowServer, although it'd still be surprising that it persists after quitting.

[mitchellh]

Oh sorry, note that on tip we did fix that IOSurface leak so if that was it, it'd be fixed on tip releases.

[mustafa0x]

Same issue here. Same exact machine (m3 max). I submitted the IOSurface leak fix. I updated to tip after it was merged. I'm not sure if it helped or not. It likely did. But ghostty is still laggy. It's odd.

[sammcj]

I've experienced this or something very much like it as well.

Over time Ghostty gets slower to appear when triggered with the hotkey and WindowServer uses between ~10-40% CPU when doing very little.

I've also noticed over time clicking between panes in Ghostty becomes less reliable, you might click to type in or select some text from one pane only to find that the pane was never activated.

• macOS 26.x
• Apple MBP M5 Max (previously also occured on my M2 Max MBP)
• 2x 4k external monitors (one running at 2.0 HiDPI so a 2x framebuffer)

I'm fairly certain that WindowServer has been very CPU heavy across macOS releases for many years (with or without Ghostty) and is heavily correlated to the resolution and number of external displays.

I wouldn't be at all surprised if this was a bug in WindowServer which Ghostty exacerbates somehow.

[pluiedev]

We won't waste our time reading AI-generated posts. Our AI policy requires posts to be written by humans.

[mustafa0x]

isReleasedWhenClosed=false might be one of the causes.

#13386

[mustafa0x]

After six days of usage, I can confirm: the fix proposed in #13386 does truly resolve the WindowServer CPU issue.

I've pushed it to a branch. Try it out:

# Requires full Xcode
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -downloadComponent MetalToolchain
mise install zig@0.16.0

git clone --branch fix-macos-transparent-titlebar-window-retention \
  --single-branch https://github.com/mustafa0x/ghostty.git
cd ghostty

# Build; output is zig-out/Ghostty.app
mise exec zig@0.16.0 -- zig build -Doptimize=ReleaseFast

# Fully quit any existing Ghostty first, then launch the patched build
open "$PWD/zig-out/Ghostty.app"

AI's explanation:

This was a multiplying leak.

Before the fix, closing a tab usually removed its controller but left an invisible, fully constructed macOS window behind—complete with titlebar views, layers, and sometimes graphics surfaces. Those windows remained registered with AppKit, so every title change or animation made macOS revisit them. Codex’s animated status was especially effective at exposing this: one changing terminal could trigger work across months’ worth of “dead” window machinery.

The old pathological process looked like this:

• 47 real tabs
• 175 terminal windows still registered—128 were closed ghosts
• About 2.06 billion backing pixels
• 9.1 GB physical memory
• WindowServer repeatedly processing all those abandoned layers and buffers

The patch changes one important timing detail. A tab-change observer used to replace itself while its own callback was still running. That confused AppKit’s ownership bookkeeping and prevented the window from being released. The fix waits until the callback finishes, then replaces the observer on the next main-loop turn. Ordinary ARC cleanup can then complete.

[dmik]

I've been experiencing the very same problem since March (1.3.1 release). At some point Ghostty starts creating new mac ports exactly every second:

2026-05-09 02:40:25.681102-0700 0x81aedc   Default     0x0                  69002  7    ghostty: (SkyLight) [com.apple.SkyLight:default] server port 0x0494ac03, session port 0x0000350b
2026-05-09 02:40:26.685415-0700 0x81aedc   Default     0x0                  69002  7    ghostty: (SkyLight) [com.apple.SkyLight:default] server port 0x0494b803, session port 0x0000350b
2026-05-09 02:40:27.682890-0700 0x81aedc   Default     0x0                  69002  7    ghostty: (SkyLight) [com.apple.SkyLight:default] server port 0x0494b703, session port 0x0000350b
…

and then eventually gets killed by the kernel at reaching exactly 305836 ports:

2026-05-09 02:40:37.681840-0700 0x81aedc   Default     0x0                  0      0    kernel: process ghostty[69002] caught allocating too many mach ports.       Num of ports allocated 305834;
2026-05-09 02:40:37.681852-0700 0x81aedc   Default     0x0                  0      0    kernel: [ghostty: killed] exiting with signal 9, force exiting the process
2026-05-09 02:40:37.681980-0700 0x81aedc   Default     0x0                  0      0    kernel: ghostty[69002] Corpse allowed 1 of 5

It happens every two-three days, I usually notice Ghostty is gone when waking macStudio after a sleep.

I built the suggested branch locally and will give it a try. macOS and Ghostty are running 24.7 here with Ghostty usually having around 10-15 tabs running a few text file managers (far2l recently but happened with mc too).

The good thing is that all far2l processes keep running after ghosty being killed and I can reattach to them after a restart but it's quite a headache when there are 10 of them.

PS. No crash reports by Ghostty itself in ~/.local/state.

[mitchellh]

Thanks, this was enough to find the issue. A fix is incoming.

[mitchellh]

#13590

[dmik]

@mitchellh thanks for quickly fixing it. What's the proper way to test it? Just build from master? I hope you will come up with a beta / nightly channel for macOS since it's always tricky to have a custom-built .app next to the official one, due to signing/permissions/etc.

[rhodes-b]

there has been a "nightly" option available before 1.0 was even released
https://ghostty.org/docs/config/reference#auto-update-channel

[dmik]

Wow, that's fantastic, thanks for the hint, already testing the tip

[dmik]

Just confirming, after two weeks, no kill issue at wakeup anymore.