Meta: macOS Tahoe (v26)
This is a tracking issue for the next release of macOS Tahoe (v26), announced on Jun 9, 2025.
TLDR STATUS: Ghostty works fine on macOS Tahoe. There are minor visual glitches here and there but they're extremely minor. The major work involved for this meta issue is adapting to the new visual design language so the app fits in better to the new look, and adopting new features for macOS Tahoe.
This issue will be closed once tip has all known issues resolved with the latest macOS release. We'll probably close this issue at some point along the way during the beta process and not wait for the final final release. I find that usually any breaking changes/bugs for app developers get cleaned up a few betas in while the OS is still ironing out its own issues.
The released version that will support this version of macOS is Ghostty 1.2.0. At the time of writing, we're on 1.1.3. If you're running a macOS beta and want Ghostty to work, you should use the tip releases (a beta for a beta, if you will).
initial quick test, all seems fine on 1.1.3 (YMMV)
The tab appearance is now inconsistent with the standard native tabs which is a little frustrating.
The tab appearance is now inconsistent with the standard native tabs which is a little frustrating.
Is this with titlebar tabs or a default config? Out of the box I didn't think we customized the tabs but I could be wrong. I'll be upgrading soon to see.
This is with the default config, to compare to how the new tab style looks... I am not sure I prefer it. However there has definitely been a design shift. This kind of tab style is used in Safari, Xcode and pretty much every app on Tahoe.
I think that just requires a recompile with Xcode 26, maybe... I haven't tried anything yet but the videos from WWDC seemed to imply new styles wouldn't be available until apps are recompiled with the latest Xcode/SDK.
Good to know it should at least be a simple fix.
The corners of the Ghostty icon appear clipped in macOS 26
@Aaron-212 I've engaged our original icon designer (Michael Flarup) to bring our icon up to the new aesthetic and to use Icon Composer so we can take advantage of all the layers.
#7559 adds macOS Tahoe and Xcode 26 builds to our CI. This doesn't update tip releases yet.
@maclong9 Can confirm a recompile gets us the new style tabs for native tabs:
https://github.com/user-attachments/assets/95f5b056-4a2b-48ef-a314-1fa574f23d13
Tab switching works perfectly on Tahoe. Really stoked. Was such a minor thing going from 3-2-1 but being able to go from 3-1 is just so nice
Tab switching works perfectly on Tahoe. Really stoked. Was such a minor thing going from 3-2-1 but being able to go from 3-1 is just so nice
Note @RafaelZasas that this will work on prior macOS versions as well. The fix here wasn't due to macOS Tahoe but due to #7523 :)
The first big batch of macOS Tahoe visual compatibility fixes went in #7588. Note that they won't be visible until #7591
@mitchellh I just installed the latest tip Ghostty but the old title-bar style is still used. Tried reinstalling Ghostty but didn't work.
Ghostty 1.1.4-main+f26dec55
Version
- version: 1.1.4-main+f26dec55
- channel: tip
Build Config
- Zig version: 0.14.1
- build mode : builtin.OptimizeMode.ReleaseFast
- app runtime: apprt.Runtime.none
- font engine: font.main.Backend.coretext
- renderer : renderer.Metal
- libxev : kqueue
# the initial-command is executed by bash by default
initial-command = $SHELL -c "tmux attach -t base; or tmux new -s base; fish"
font-family = "MonoLisaVariable Nerd Font"
font-size = 18
font-thicken = true
font-thicken-strength = 100
background-opacity = 0.8
background-blur = 30
# FIXME: gruvbox material has a minor issue in ghost text color
# theme = gruvbox-material
theme = GruvboxDark
macos-titlebar-style = tabs
macos-icon = microchip
title = " "
Yes, please reread my message. That’s expected
#7594 is related to this issue, it updates our menu to have icons as is typical and recommended for the new design system
Tip/Tahoe note... Not sure whether to open a new issue vs. just comment, but wanted to let you know that if you sweep out some text in ghostty and copy it, it'll crash the app. Double click the selected text does the same. This is on tip on Tahoe.
Tip/Tahoe note... Not sure whether to open a new issue vs. just comment, but wanted to let you know that if you sweep out some text in ghostty and copy it, it'll crash the app. Double click the selected text does the same. This is on tip on Tahoe.
I'm unable to reproduce this. I tried selecting text, double clicking the selected text, copying via right click menu and ⌘+c inside and outside of both vim and tmux. Installed via brew install --cask ghostty@tip.
Edit: repeated the steps in various order in fish, bash and zsh with no crash, curious if it happens after restarting Ghostty.
I just poked around some more to try to diagnose. It is related to a custom shader. If I comment out the shader, double clicking some text, command-c, etc., works fine. This is new behavior with tip/tahoe (I've used the same shader for ages). Didn't think of it being shader related, so that was a surprise. Here's the shader, for reference, though I don't think it's specific to it?
As of #7616, our tip releases are now built with the macOS 26 SDK, so the new visual style should be visible.
Icon updated here: https://github.com/ghostty-org/ghostty/pull/7638
Looks like window-decoration=none doesn't work tip 9d922e1c / tahoe.
Main Ghostty process opens fine, but terminal windows never launch.
v1.1.3 works as expected.
Thanks @tbiehn, fixed in #7644
I'm noticing excess unfocused, idle CPU usage in Ghostty on Tahoe. Ghostty should idle unfocused at 1.5% max (but typically more around 0%). On Tahoe, I'm sometimes seeing 10 to 15%, which is unacceptable for power usage. I asked in Discord and one user reported not seeing this on Sequoia. I don't have my Sequoia drive w/ me right now to verify.
The only thing I suspect so far is that it has something to do with the new Tahoe native tab bar (that macOS owns, not us). I only seem to get this when the tab bar is visible.
I'm making this comment in case others see this and as a reminder to myself to keep an eye on this.
I'm noticing excess unfocused, idle CPU usage in Ghostty on Tahoe. Ghostty should idle unfocused at 1.5% max (but typically more around 0%). On Tahoe, I'm sometimes seeing 10 to 15%, which is unacceptable for power usage. I asked in Discord and one user reported not seeing this on Sequoia. I don't have my Sequoia drive w/ me right now to verify.
The only thing I suspect so far is that it has something to do with the new Tahoe native tab bar (that macOS owns, not us). I only seem to get this when the tab bar is visible.
I'm making this comment in case others see this and as a reminder to myself to keep an eye on this.
My CPU usage:
- Lots of screen updates: 50% to 100%
- Minimal updates but on screen: ~5%
- No updates but on screen: 1.5% to 5%
- Open but not on screen: ~0%
To add with a terminal based text editor (hx) the usage will idle around 1.5% for a little while when unfocused and then drop to around 0% after a brief time period.
Similar results with or without multiple tabs being open.
I just poked around some more to try to diagnose. It is related to a custom shader. If I comment out the shader, double clicking some text, command-c, etc., works fine. This is new behavior with tip/tahoe (I've used the same shader for ages). Didn't think of it being shader related, so that was a surprise. Here's the shader, for reference, though I don't think it's specific to it?
This is now fixed in one of the recent nightly builds. I had occasionally been trying the shader again to see if it stopped causing the crash, and at some point in the last week or so it went back to working as usual. Just an FYI. Thanks for all the work.
On 1.1.3, going to full screen and back causes the window to be entirely transparent except for the blur. Works fine if I disable the blur.
https://github.com/user-attachments/assets/0c3c37fa-02c7-4f28-8348-3842a5c8bab4
Edit: Seems to work fine on tip but will leave this here if anyone faces it.
In macOS 26, when i open a terminal through vs code or cursor with this command it opens two tabs one of which shows blank and one opens in root, i have to use the command again to open a 3rd tab which opens in the code directory correctly.
VS code command
After cmd+shift+c in my case opened 2 tabs one in root another makes the terminal seem blank
In the final image observe the active tab is ghostty on the top left, it shows nothing when i select the 2nd tab that opened via this method.
Ideally it should open one tab in the current coding directory. macOS terminal seems to work fine with this command.
The command palette doesn't gain focus when triggered with the shortcut on Tahoe.
https://github.com/user-attachments/assets/79c4bd54-3315-4bb0-90c0-38cddddd6fc4
The command palette doesn't gain focus when triggered with the shortcut on Tahoe.
(That's new with beta 6, for the record. It's not 100% consistent, though -- there have been situations where this worked fine at a stretch; unfortunately not reproducible so far.)