Cmd-D Cmd-Shift-D Split Panel support in terminal

[sasha-id]

What problem does this solve?

Add default keybindings for split panes: Cmd+D / Cmd+Shift+D

Cmd+D — split vertically (new pane right)
Cmd+Shift+D — split horizontally (new pane below)

What would the ideal solution look like?

No response

Alternatives you've considered

No response

[davidpoblador]

Thanks for the suggestion @sasha-id! After digging in, I'm going to defer this one. Laying out the reasoning so it's on record.

Where FF stands today: there's zero split-pane plumbing. Every terminal tab is one TerminalView wrapping one ghostty_surface_t. Ghostty's GHOSTTY_ACTION_NEW_SPLIT action is explicitly dropped in Sources/Terminal/TerminalApp.swift:handleTerminalAction — so even though Ghostty has a full split system upstream (ghostty_surface_split, SplitTree, TerminalSplitTreeView), FF deliberately doesn't use any of it.

Native implementation scope is medium-to-large:

• New split-hosting view (NSSplitView or custom) wrapping multiple TerminalViews
• TerminalSurfaceCache has to grow from UUID -> TerminalView to UUID -> tree-of-TerminalViews
• Focus tracking splits from "visible" vs "focused" at the split-container level (currently visibleSurfaceIDs is a flat set)
• Snapshot serialization (workspace tab state) has to encode the split tree, with migration for existing workstreams
• Keyboard shortcut routing has to reach the focused leaf, not the tab container

That's a real architecture change. FF's mental model today — one surface per tab, tabs are the navigation unit — is clean specifically because there's no intra-tab layout. Panes add a second axis that interacts with tab close, archiving, occlusion, and snapshot restore.

What works right now: users who have tmux mode on can press Ctrl+B % / Ctrl+B " inside the Coding Agent tab today, and can remap those however they like in ~/.tmux.conf. For the agentic terminal workflow that FF targets, that covers most of the split-pane need.

Also worth noting: Cmd+D has also been requested by PR #440 for the Changes tab. If we do eventually ship native splits, Cmd+D is the macOS convention for split (Terminal.app, iTerm2, Finder) and should belong to splits — but that's moot unless and until this is scoped properly.

Decision: keeping this issue open but marking as later. If this becomes a recurring ask with clearer use cases beyond "I want splits," it deserves a real design doc before implementation.