Repository navigation
Window fails to fully close on MacOS 26 (Tahoe) #8952
Description
Activity
Does not reproduce for me on released versions of macOS. Report the
issue to Apple since you seem to be running a beta macOS. And note that
if you want kitty to quit when its last window is closed, unlike native
mac programs, use the option for it in kitty.conf.I understand that this is the beta and bugs are expected. But since this version of the OS will be released relatively soon I wanted to give you a head start on looking into the issue.
Sorry, I dont have the spare time to workaround bugs in beta software
produced by trillion dollar corporations. If macOS is released with
this bug I will look into finding workarounds, until then, you can
workaround it yourself trivially in kitty.conf with macos_quit_when_last_window_closedI wasn't trying to add to your workload I'm amazed and thankful that you maintain such an awesome app. I thought it might be helpful to know that this seems to be a bug in a major OS that a lot of your users use. For me it's a mild annoyance that I can work around and will continue to use Kitty. In a few weeks it will be a problem for a lot of people and I figured you'd want to know.
I don't think this is a MacOS "bug" since every other app I run works without issue. More likely a subtle change in how MacOS works that, like it or not, is coming. I'll leave the decision to you on how to handle it, I was just trying to be helpful.
I'm well aware of this, see #8893 or #8882
It's simply not my policy to waste my time on bugs in pre-release
versions of macOS. I spend quite enough of my time working around the
myriad bugs existing in released versions. Not to mention reverse
engineering the internal details of Cocoa given Apple's appalling lack
of documentation. As I said if and when the new version is released with
the bug I will work around it, until then, I live in the hope of a
modicum of competence for all those trillions of dollars.A change of behavior in an OS that silently breaks existing working
applications with no warning and no deprecation period is clearly a bug
in the OS. Apple really sucks in that they regularly break working
applications, in contrast to say Microsoft. Oh well, at least they
aren't as bad as Wayland.- added a commit that references this issue
on Sep 5, 2025 I'm sorry that Apple is a pain in the ass sometimes. None the less I appreciate you fixing this.
- added a commit that references this issue
on Sep 5, 2025 Goes with the territory. Every OS vendor is a pain the ass, in different
ways :) I am actually not 100% sure this fixes it in all scenarios.
There is no reason it should be necessary given kitty already calls
NSWindow::close so this is basically papering over whatever the actual
issue with NSWindow::close Apple has introduced. Hopefully the papering
over is sufficient, we will see.Reacted by ykai55 and Marius KleinerI'm happy to test it out to see since I can reliably reproduce. I assume this will go into the nightly build by tomorrow? If not I can always try compiling locally.
Yes, nightlies are built from master once every 24 hrs.
8 remaining items
I am using 0.44 now (also tried with
kitty -c NONE), and do not see this left open clear window, but the kitty icon is still shown when using the expose feature. It does not hurt much, but I just wanted to mention it. Maybe someone has an idea, where this might come from.
Unsure whether the "closed" status means that this should be fixed in the latest release?
I'm running 0.44.0 on 26.1, and still seeing this.
Fix is too strong a word. Apple's bug has been worked around and yes the
workaround in in 0.44.0. Does not reproduce on my mac 26.1 anymore.@kovidgoyal thank you. Assumed I was having the same issue, but possibly this is different (or even introduced by the workaround?) What I'm actually seeing is this: occasionally, when I try to click on the desktop, Kitty is activated (Kitty's menus are displayed in the menu bar) instead of the click going to Finder. This has happened even after revealing the desktop with the touchpad gesture.
Once this happens, I can only get clicks to go to the desktop again by quitting Kitty.
See if this helps you
2351db7See if this helps you 2351db7
Sorry that refuses to compile here, complaining
typeofis undeclared. Previous commit builds and works fine.% git clone https://github.com/kovidgoyal/kitty Cloning into 'kitty'... [...] Resolving deltas: 100% (73339/73339), done. % cd kitty % ./dev.sh build Downloading macos-64.tar.xz Downloading NerdFontsSymbolsOnly.tar.xz Dependencies downloaded. Now build kitty with: ./dev.sh build [18/86] Compiling [cocoa] glfw/window.c ... done Compiling [cocoa] glfw/cocoa_window.m ... clang -MMD -DNDEBUG -D_GLFW_COCOA -D_GLFW_BUILD_DLL -DGL_SILENCE_DEPRECATION -I/Users/mika/Code/kitty/dependencies/darwin-arm64/include -Wextra -Wfloat-conversion -Wno-missing-field-initializers -Wall -Wstrict-prototypes -std=c11 -pedantic-errors -Werror -O3 -fwrapv -fstack-protector-strong -pipe -fvisibility=hidden -fno-plt -D_FORTIFY_SOURCE=2 -flto -mbranch-protection=standard -fPIC -c glfw/cocoa_window.m -o build/glfw-cocoa-glfw-cocoa_window.m.o glfw/cocoa_window.m:2327:16: error: call to undeclared function 'typeof'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 2327 | __weak typeof(nw) weakSelf = nw; | ^ glfw/cocoa_window.m:2327:16: error: expected identifier or '(' glfw/cocoa_window.m:2329:22: error: expected identifier or '(' 2329 | __strong typeof(weakSelf) strongSelf = weakSelf; | ^ glfw/cocoa_window.m:2330:17: error: use of undeclared identifier 'strongSelf' 2330 | if (strongSelf) strongSelf.collectionBehavior = old; | ^ glfw/cocoa_window.m:2330:29: error: use of undeclared identifier 'strongSelf' 2330 | if (strongSelf) strongSelf.collectionBehavior = old; | ^ 5 errors generated. The following build command failed: /Users/mika/Code/kitty/dependencies/darwin-arm64/python/Python.framework/Versions/Current/bin/python3 setup.py develop exit status 1Yeah, I forgot ARC is not enabled for these. Needed to use __unsafe_unretain but it doesnt fix the zombie window issue anyway, so never mind.
Some further investigation, with the following patch:
diff --git a/glfw/cocoa_window.m b/glfw/cocoa_window.m index a4c234d09..e0ff60bbb 100644 --- a/glfw/cocoa_window.m +++ b/glfw/cocoa_window.m @@ -1939,6 +1939,16 @@ int _glfwPlatformCreateWindow(_GLFWwindow* window, const _GLFWwndconfig* wndconf return true; } +static void +kill_tahoe_ui_window(unsigned long long timer_id UNUSED, void *data UNUSED) { + for (NSWindow *window in [NSApp windows]) { + if ([NSStringFromClass([window class]) isEqualToString:@"TUINSWindow"]) { + // this is a weird nswindow macos creates since Tahoe when you close an NSWindow + NSLog(@"%@ %lu", window, [window retainCount]); + } + } +} + void _glfwPlatformDestroyWindow(_GLFWwindow* window) { GLFWWindow *w = window->ns.object; @@ -1971,6 +1981,7 @@ void _glfwPlatformDestroyWindow(_GLFWwindow* window) [w setFrame:frame display:NO]; [w close]; // sends a release to NSWindow so we dont release it window->ns.object = nil; + glfwAddTimer(s_double_to_monotonic_t(0.2), false, kill_tahoe_ui_window, nil, nil); } static NSScreen*
we see that after closing the NSWindow, sometime later, macOS creates a "TUINSWindow" and that is the zombie window. I am guessing TUI here stands for Tahoe UI. I can find no Apple documentation about this, why it is created, how to prevent is from being created, etc. If I had to guess, I'd say its related to Apple's glass effects.
Just guessing here, as indeed there's no proper documentation on this at all:
Googling would seem to indicate
TUINSWindowpredates Tahoe. The following hints atTextInputUIbeing the likely culprit:https://developer.apple.com/forums/thread/742826
We also have the following in the Chromium codebase:
// Handle ordering groups for AppKit native windows. For instance, the // `TUINSWindow` is added and removed by AppKit when caps lock is active. // See https://crbug.com/369970893 for more details. if (![childWin isKindOfClass:[NativeWidgetMacNSWindow class]]) { [self maybeRemoveTreeFromOrderingGroups]; }
Yeah, then I guess that's not the cause, which kind of makes sense as
its frame is 0,0 to 500,500 which is not matching the area of the closed
window anyway. Printing out the list of windows in that timer callback
shows that the only window left is the TUINSWindow meaning, the kitty
window has been properly remove from NSApp.windows. So not sure what
else to do here. Just live with the bug I guess, or set
macos_quit_when_last_window_closed to yes in kitty.conf.Reacted by Devin Collins- added 2 commits that reference this issue
on Dec 8, 2025 I am using 0.44 now (also tried with
kitty -c NONE), and do not see this left open clear window, but the kitty icon is still shown when using the expose feature. It does not hurt much, but I just wanted to mention it. Maybe someone has an idea, where this might come from.
I just installed Tahoe 26.4 and this issue is gone. So either they changed something or the installation cleared some leftover stuff :D
- added a commit that references this issue
on Jul 2, 2026 - added a commit that references this issue
on Jul 8, 2026
Describe the bug
When using Kitty on MacOS after closing a window (using either cmd+w or
exiton the last pane the window doesn't show but seems to still be there. Attempting to click on other applications doesn't work as they seem to be "behind" the non-existent kitty window. In the attached screenshot you can see the empty window when using the expose feature on MacOS.To Reproduce
Steps to reproduce the behavior:
Screenshots
Environment details
Additional context
Problem persists even when kitty is opened with
--config NONE