There are multiple parts of this problem, and the terminology is a bit confused around what to call each part. So I'll briefly run though how I see it, and the terminology as I understand it, as a contribution to this discussion.

I see terminal multiplexing as providing the surfaces that the terminal then renders the shells in. I think the standard term for this is "pane", and ghostty I guess calls these "splits", which is a bit ambiguous, as a "pane" could be a whole window, or tab if there are no splits in that space, but if there is, what do you call each part of the split? But as far as features for the basic multiplexing, I think Ghostty is pretty much there, with the one part that might be considered missing is a way to move around splits. #1525

Moving on from there is the ability to restore a grouping of windows, tabs and splits. Ghostty has this, in the single case of closing the application, and restoring windows existing when closed. But no ability to restore the contents inside the shell, basically you get a new shell. OS X's Terminal.app has a very elegant way to handle this, restoring the scrollback and command history per window. Lilyball has an interesting writeup of that here: #2679. With the implementation of the TERM_SESSION_ID env var, we could get the command history restoration for free, leveraging the shell. It's not clear to me how the scrollback restoration works, I believe that is something the terminal handles, and this makes sense to keep there, as it would need some integration, or be a horrible kludge. (but, if we had a unique ID in the vein of TERM_SESSION_ID, the user could use other session management tools to save and restore to windows themselves.) Issue for the scrollback side of things: #1847

Then we reach the topic of discussion, a method of saving states of these groupings, and the contents within, at user direction, and some management of these states. I think the previous two parts are necessary for any session to exist, so they need some attention first, but it would be good to know the direction intended to make sure the implementation makes sense for the desired end goal. This would be things like at what level of granularity should a session be? Just splits within a tab? Tabs and their splits within a window? (My vote). Or all open windows at once?

The goal is goal of this feature request is to replicate the workflow that you would get with a terminal multiplexer.

For the granularity, GNU Screen was first release in 1987, when hardware terminals were still a thing, and software terminal emulators with tabs and splits wouldn't come much later. At the time, one GNU Screen session corresponded to one hardware terminal or to one terminal emulator window. In a more modern workflow, one Tmux or Zellij session would correspond to one window of a non-multiplexiing terminal (Foot, Xterm, st, Alacritty, etc).

The analogue of the window for a non-multiplexing terminal in a multiplexing terminal (ex. Ghostty, Kitty, Konsole) is, well, still the OS window. So, a window should be a session.

As for the session management itself, there are three aspects to consider (aside of the UI): initialization, reattachment, and restoration

Session Initialization

This is setting up a working environment, --command can be thought of as a very minimal and limited session initialization. There is no way for a window to set up a completely different session, because session initialization is considered config, and config is as the process level.

Windows should be able to run their own session initialization scripts instead of being confined to the command config of the process.

This is related to #3880

Session Reattachment

IMHO, this is the primary selling point of session management in terminal multiplexers.

When you kill a terminal running a terminal multiplexer, you do not actually kill the shell: the terminal multiplexer is still running in the background, and the shells were running inside the multiplexer, so they never got orphaned and killed. Then, a new terminal can connect to the multiplexer, and will display the same exact instance of the same shells.

Ghostty can already run heedlessly (--initial-window=false --quit-after-last-window-closed=false), so session reattachment can be implemented in a similar way as way as with terminal multiplexers: when the user kills the window, none of the processes that were running get killed, and the scrollback buffer doesn't get freed from memory, everything is still running within the Ghostty process as if the window was never killed in the first place, except there's no window.

Then, when the user presses a keybinding and selects the headless session, the session existing in the window gets detached, and the old session, still running, and its relative scrollback buffer(s) get attached to that window.

This requires to figure out two steps:

• How to keep the "window" (session) running without the window
• How to attach the session to a window

Session Restoration

IMHO, this one isn't very important and it's not even a requirement.

This would allow serialization of the window state to disk, with the ability to open a session look-alike with the same scrollback buffers, but new instances of the shells.

• I'm also highly interested in testing Ghostty out without tmux in the way, I use tmux basically the entire day, as soon as I open Ghostty, tmux takes over with this command
• I use the tmux-resurrect plugin so all my sessions are restored when I close and re-open Ghostty
• I use tmux to easily switch between my different github repos, I use ThePrimeagen's tmux-sessionizer
• So with keymaps I jump to my different projects hyper+t+j -> dotfiles, hyper+t+u obsidian repo, hyper+t+l -> blogpost, hyper+t+r -> daily note, etc, etc
• Also with hyper+t+n I get an fzf menu of my different directories, so I can create a session out of any of those that I don't have keymaps for. And I just switch to them using the tmux sessions window (image below)
• Also if I tap left_shift on my keyboard, I jump back to the previous or alternate tmux session
• I honestly don't care about remote servers via SSH, my main goal is the session management features, if on a remote server I'll use tmux in that case, but I'd like to have a session management option in Ghostty to use the native terminal instead of basically be using tmux