macOS: option to draw our own tabs instead of native window tabs

[pedronaugusto]

On macOS every native tab is its own NSWindow. Open three tabs and the accessibility API sees three windows, so tiling window managers that read it (AeroSpace, yabai) tile the tabs instead of the window. Today the only way to use Ghostty with a tiler is to not use tabs. #10711 asked for this, it was closed because users can't open issues here, so, discussion.

My proposal is a macos-non-native-tabs option, off by default. When on, one NSWindow holds all its sessions and Ghostty draws the tab bar itself, in the titlebar or in its own row depending on macos-titlebar-style. Turn it off and nothing changes.

In #5880 pluiedev wrote: "That's a limitation of native macOS tabs... We intend to switch to a custom tabbing solution later on, due to all the bugs native tabbing has."

I have it implemented and running as my daily driver: https://github.com/pedronaugusto/ghostty/tree/custom-tabs-split. Tab bar, drag to reorder, tear off, merge, undo/redo, per-tab colors and titles, session restoration. Swift unit tests, four XCUITests, and a scripted suite that drives the real app through a bunch of end-to-end scenarios.

Caveats: built and tested on macOS 26 only. There's a separate rendering path for pre-26 and it runs, but I have no 13-15 machine to actually try it on. I haven't tried it with VoiceOver. One thing I noticed and didn't fix: with macos-titlebar-style = tabs and non-native fullscreen the window frame drifts a few points per round trip. It does that on main too.

Also, full disclosure, the code was written with Claude Code, heavily. I set the goal and constraints, reviewed everything and tested, plenty of rounds. I'll open the PR once vouched, after this has an issue.

[BarutSRB]

@pedronaugusto Why? OmniWM already solved this, no need for such changes in Ghostty.
https://github.com/BarutSRB/OmniWM

If sending PR to Aerospace based on OmniWM fix make sure to give credit.

[pedronaugusto]

Glad OmniWM works for you, but this thread is about Ghostty. OmniWM is one window manager, and it only runs on macOS 26 on Apple Silicon. Whatever it does with tab groups internally doesn't change what Ghostty shows to everything else.

From Ghostty's own docs (https://ghostty.org/docs/help/macos-tiling-wms): "macOS native tabs are represented as separate windows in the macOS window manager API. This is the API that Yabai, Aerospace, and other tiling window managers use to manage windows on macOS." Same page, a bit further down: "Longer term, we'd like to implement a custom tabbing solution that doesn't rely on macOS native tabs. This would allow us to better integrate with macOS tiling window managers." So this is that. It's off by default, nothing changes for anyone who doesn't turn it on, OmniWM users included.

Nothing here goes anywhere near AeroSpace. The whole point is that window managers shouldn't have to work around this at all.

[BarutSRB]

You might be right. My concern is mostly about scope and long-term maintenance. A terminal is already a very complex piece of software, and on macOS I generally think it makes sense to follow the operating system’s native behavior rather than maintain a substantial parallel implementation primarily to accommodate tiling window managers that intentionally work outside those defaults.

For some perspective, your current non-native tabs work appears to add 4K+ LOC of feature related code. That is a significant amount of additional code to own, test, debug, and maintain long term.

I can definitely see the argument for supporting it, but personally I would rather see Ghostty stay close to the platform conventions and leave tiling window managers to handle the integration issues on their side. Just my two cents.

[pedronaugusto]

Yeah, about 4.4K lines plus 600 of tests, 2.7K of it actual code, no argument there. Most of that is tabs touching everything: restoration, undo, drag and drop, tear off and merge, AppleScript, the command palette, and all of it has to keep working. It's off by default, and with it on the bar looks like the native one, it just stops being N windows. Safari draws its own tabs, so there's precedent. And you proposed the same thing in March in #11713, so we've clearly both wanted this at some point.

The docs page I linked calls this a limitation of the macOS APIs and says longer term they want a custom tabbing solution, so I went and built one. It's five commits that each build and pass the tests on their own, so it reviews in pieces. Been using it daily, works beautifully.