[mac] Ghostty slow with time. isReleasedWhenClosed=true seems to help.

[mustafa0x]

Ghostty starts out fine for me, but after several days of opening and closing lots of tabs, both Ghostty and WindowServer begin using a lot of CPU. Activity in a terminal (especially frequently changing text or window titles) then makes the problem much worse. Restarting Ghostty clears it, which made this feel like something was building up over time.

I added some diagnostics and found that closing a tab removes its terminal session, but part of its macOS window remains alive. I reproduced this reliably in a fresh build: after closing 12 tabs, 12 leftover windows were still being tracked by macOS. I also tested 20 close cycles with the change below, and every closed window was released.

macos/Sources/Features/Terminal/Window Styles/TerminalWindow.swift

 override func close() {
     tabTitleEditor.finishEditing(commit: true)
+
+    // NSWindowController disables this by default. Allow AppKit to release
+    // the remaining window after Ghostty has finished closing it.
+    isReleasedWhenClosed = true
+
     NotificationCenter.default.post(
         name: Self.terminalWillCloseNotification,
         object: self
     )
     super.close()
 }

Is there a reason Ghostty needs to keep these windows around after they’re closed, or does this look like a safe fix?

[bo2themax]

isReleasedWhenClosed is already true by default, did you update the version that fixed the surfaceview's retain cycle?

[mustafa0x]

I created a repro: main...mustafa0x:ghostty:repro-macos-terminal-window-retention

git fetch https://github.com/mustafa0x/ghostty.git repro-macos-terminal-window-retention

git switch --detach FETCH_HEAD

zig build -Demit-xcframework
macos/build.nu --configuration ReleaseLocal

GHOSTTY_TERMINAL_WINDOW_CHURN=12 \
  macos/build/ReleaseLocal/Ghostty.app/Contents/MacOS/ghostty \
  --config-file=/dev/null \
  --initial-window=false \
  --macos-titlebar-style=transparent

After roughly 26 seconds, it should print:

GHOSTTY_CHURN_RESULT closed=12 still_alive=12 in_nsapp_windows=12 with_controller=0 terminal_windows=15 tab_members=3

You can attach Xcode then and capture its memory graph (note: I'm on macOS 15.7.7 and confirmed).

[bo2themax]

Seems the test was written with the assumption that, closeTabImmeditely will release the window and the controller immediately, which is wrong.

Did you run the same test with basic window controllers outside of Ghostty?

[mustafa0x]

Sorry, I should’ve explained that better. The test doesn’t expect anything to be released immediately. It waits eight seconds after the last close, so Ghostty’s five-second undo window has already expired.

I also updated the test to track the controllers directly. At the end, all 12 controllers are gone, but all 12 closed windows are still alive:

closed=12 controllers_alive=0 windows_alive=12 windows_in_nsapp=12

And yes, I ran the same tab pattern in a small AppKit app using ordinary XIB-loaded window controllers, with isReleasedWhenClosed left false. All 12 controllers and windows were released, leaving only the three tabs that were meant to stay open.

Update: I also repro'ed on macos 26.5.2.

[mustafa0x]

Here’s the standalone AppKit test: https://github.com/mustafa0x/appkit-window-lifecycle-control

It keeps the closed controllers around for five seconds, like Ghostty does for Undo. Once that time passes, all 12 controllers and windows are cleaned up.

[mustafa0x]

I told ai to investigate whether the patched ghostty version I'm using is healthy. It responded:

Yes—the patched Ghostty is cleaning up correctly.

After about 9½ hours and 48 window/tab closures:

• 94 terminal windows created − 48 destroyed = exactly 46 currently open.
• AppKit also reports exactly 46 terminal windows and 46 tab members.
• Across 712 samples, only two temporary mismatches appeared during closure; they cleared within 1–2 seconds.
• Surface counts also balance exactly: 94 created − 39 destroyed = 55 live. Surfaces can outnumber windows because of splits.
• No closed windows are accumulating.

I requested one lightweight live census; I did not attach a profiler or disturb Ghostty. The original closed-window retention bug appears fixed.

[dgmora]

AI assistance disclosure: this investigation was done with Claude Code: it ran the diagnostics (footprint, vmmap, heap, leaks --trace) against my live Ghostty process, analyzed the results, and checked the git history; all numbers are real measurements from my machine. I reviewed the output, but I don't have knowledge of ghostty's code. Only hoping that this extra report can help with the diagnosis

---

Independent confirmation on an older stable and a different titlebar style, so this looks neither config-specific nor a recent regression.

Env: Ghostty 1.2.2 stable (7071a22cb), macOS 26.5.1, macos-titlebar-style = tabs, 41 days uptime, 9 windows open.

heap(1) shows 267 TitlebarTabsTahoeTerminalWindow instances with 9 windows open: every window/tab closed in 41 days is still resident, along with its titlebar subgraph (267 each of NSToolbar, NSToolbarItem, and the two NSHostingViews). That accounts for ~540 MB of dirty malloc, roughly 2 MB per closed window. (The rest of my footprint is GPU memory for the open windows, not part of this.)

On the SurfaceView retain cycle question above: I don't think that explains the window retention. On 1.2.2 the content side deallocates cleanly, exactly 9 TerminalController, 9 SurfaceView, 9 NSHostingView<TerminalView>, while the windows still accumulate.

leaks --trace on one retained window supports your isReleasedWhenClosed finding: none of the 179 roots is an ownership edge. 128 are _viewRoot and 21 are _window back-pointers from objects the window itself owns, 1 is NSApplication._previousKeyWindowX, and 3 paths land on a single stale autorelease-pool slot. No live owner at all is what an unbalanced retain looks like, since an over-retain needs no pointer to exist. It also explains why leaks reports almost nothing unreachable: each retained window and the titlebar/toolbar objects it owns only reference each other, so the group would be reported as garbage if those false-positive roots (stale registers, GPU driver statics, pool pages) didn't make it look reachable. Reading real retain counts is blocked on stable builds ("Process is not debuggable").

Anyone can check their own instance with heap $(pgrep -x ghostty) | grep TerminalWindow; the window-class counts never drop as tabs are closed.

[mustafa0x]

#11799 (comment)
you can try the change here. it helped for me.

[mitchellh]

I believe this fixes it @mustafa0x: #13601

[shaanmajid]

One MRE:

1. Launch Ghostty with the minimal configuration below.
2. Open a window and add a second native tab.
3. Initiate a scroll inside the added tab.
4. Before momentum finishes, close the tab (e.g., via Cmd + W)
5. Wait past the Undo timeout.
6. Observe that the closed tab's view and PTY remain.A reverse-reference trace hows NSWindowAuxiliary._latchedViewForScrollEvents retaining the view.

Ghostty version

Ghostty 1.3.2-main-+2ee42adc7
Build mode: ReleaseFast
Channel: tip

OS Version Information

macOS 26.5.2 (25F84), Apple Silicon

Minimal Ghostty Configuration

macos-titlebar-style = tabs
confirm-close-surface = false
shell-integration = none
command = direct:/bin/sleep 600

[shaanmajid]

In practice, I would expect the cell selection trigger to be the much more common cause of these leaks; selecting any text throughout the lifespan of a tab would cause a memory + PTY leak. In practice, this caused me 100+ orphaned PTYs over an 18 day session, and 12GB of memory consumption even after closing all windows and tabs.

On a flight right now lol but I’ll try to provide more info when I’m on the ground.

When looking into this a few days ago, I came to the vague conclusion that an approach similar #9760 might help. Right now cleanup occurs as a side effect of 'deinit’, but remaining Swift refs prevent proper cleanup. An explicit Surface.free() after Undo expiry when closing a tab seemed to me like a reasonable guarantee to free the terminal, but unsure if there’s any architectural reason this shouldn’t be pursued.

(sorry if i’m fumbling any of the terms, I tried learning all this stuff for the first timein the process of exploring this bug!)

[mitchellh]

Thanks @shaanmajid I think I've found a retain loop w/ selection at least... looking now...

[mitchellh]

@shaanmajid Found it: #13676

[shaanmajid]

Ahhhh forgot to follow-up, but that's awesome, thank you for the quick fix!

[mitchellh]

I'm going to mark this as closed/complete since we fixed multiple issues. If there are more and specific issues, lets open new discussions.