Feature: disable default keybinds when in alternate screen mode

[andrewgazelka]

Summary

Add a mechanism to disable default keybindings when the terminal is in alternate screen mode. This would allow TUI applications (vim, neovim, helix, etc.) to receive keybinds that Ghostty normally intercepts.

Use Case

When building or using full-fledged TUI editors, users need keybinds like cmd+a (select all) to be sent to the application rather than handled by Ghostty. Currently, Ghostty's default cmd+a=select_all binding intercepts this even when running vim where cmd+a might be mapped to a custom action.

This is especially important for users who are not experienced with vim bindings and want to use familiar macOS keybinds within their TUI editor.

Proposed Solution

Add a new keybind trigger prefix (similar to performable:, unconsumed:, global:, all:) that only activates when not in alternate screen mode. For example:

# Only select_all when NOT in alternate screen (normal shell)
keybind = normal_screen:cmd+a=select_all

# Or inversely, unbind in alternate screen
keybind = alt_screen:cmd+a=unbind

Alternatively, a more general condition system:

keybind = when:!alternate_screen:cmd+a=select_all

Related

• scroll_* bindings should respect "performable" and do nothing in alt screen #6765 - scroll_* bindings should respect "performable" in alt screen (similar concept, narrower scope)
• Introduce performable: prefix for keybind triggers to passthrough if they would do nothing #4328 - performable: prefix implementation

Additional Context

This would enable seamless keybind sharing between the terminal shell and TUI applications, making Ghostty more suitable as a primary environment for terminal-based development workflows.

[neurocyte]

This would be really good. Flow (the editor) breaks with each new Ghossty release because basic features are hidden by new default keybinds in Ghostty.

[rhodes-b]

This seems similar to previous requests on disabling specific keybinds when in specific applications (ex: neovim) which has always been deferred to #2353 where during the tui configuration you will disable keybinds then re-enable on the tui exit using some form of programmatic control

This is especially important for users who are not experienced with vim bindings and want to use familiar macOS keybinds within their TUI editor.

Im not sure I see this point, its then up to the tui to use more "traditional" keybinds which many don't offer oob anyways because everyone is so attached to everything needing vim keybinds. I also think that many actions in many applications don't have a "traditional" equivalent a simple example is entering different modes for modal editors

keybind = when:!alternate_screen:cmd+a=select_all

extremely unlikely to happen the original goal of the configuration file from mitchell was to never support any sort of control flow like conditionals which is why there is unique syntax to circumvent some of that like optionals with ?