Unbinding Ctrl+Shift+P sends raw CSI-u sequence (2;6u) to the terminal

[ak24watch]

Ghostty version

ghostty --version
Ghostty 1.3.0-dev+0000000

Version
  - version: 1.3.0-dev+0000000
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 7.0.0-27-generic
  - desktop env   : other
  - GTK version   :
    build         : 4.22.2
    runtime       : 4.22.4
  - libadwaita    : enabled
    build         : 1.9.0
    runtime       : 1.9.0
  - libX11        : enabled
  - libwayland    : enabled```

## Operating System

Ubuntu 26.04

## Configuration

```ini
keybind = ctrl+shift+P=unbind

Steps to reproduce

1. Configure:

   keybind = ctrl+shift+P=unbind
   

2. Restart Ghostty.
3. Open a Ghostty i used bash shell
4. Press Ctrl+Shift+P.

Expected behavior

Ctrl+Shift+P should no longer trigger Ghostty's "close all tabs/windows" action.

The key should remain available for terminal applications (e.g. flow, fresh terminal editors) without inserting a visible escape sequence at a normal shell prompt.

Actual behavior

Pressing Ctrl+Shift+P inserts:

2;6u

at the shell prompt.

Additional information

I want to unbind Ghostty's default shortcut so terminal applications can use Ctrl+Shift+P. However, at the shell prompt the raw CSI-u sequence (2;6u) is inserted, which is unexpected.

this happens to all keybindings when made unbind in config

Is this the intended behavior of unbind, or is this a bug?

[MentalOfCrow]

This is the intended distinction between unbind and ignore.

unbind only removes Ghostty's action. After that, the key is forwarded to the child process, and a modified key that has no legacy single-byte representation is encoded as a terminal escape sequence. Ctrl+Shift+P is represented by the CSI-u/kitty keyboard protocol as approximately:

ESC [ 112 ; 6 u

(112 is the code point for p; the modifier value represents Ctrl+Shift.) A terminal application that supports the protocol consumes that sequence as a key event. Bash/readline at a normal prompt does not assign meaning to this particular modified key, so parts of the sequence can become visible in the edit buffer. That does not mean the old Ghostty action is still firing.

There are therefore two different configurations:

# Make the key available to the program running in the terminal:
keybind = ctrl+shift+p=unbind

# Make it do nothing and send nothing to the child:
keybind = ctrl+shift+p=ignore

You cannot simultaneously forward the key to an application and guarantee that an unrelated shell which does not understand its encoding displays nothing. For flow or an editor, configure the application/framework to support CSI-u/kitty keyboard events (or bind the received Ctrl+Shift+P there). If the application only understands legacy terminal input, it cannot distinguish Ctrl+Shift+P from every older Ctrl-key encoding; map a sequence the application supports, or choose another shortcut.

You can verify the bytes outside readline with cat -v, press the key once, then exit with Ctrl+C. Using ignore should produce no bytes; using unbind should show the forwarded escape sequence.

If this clarifies the behavior, please mark it as the accepted answer so future users can find the unbind versus ignore distinction quickly.

[ak24watch]

my question was i want unbind and no seq eject in terminal, is it possible without ignore?

[MentalOfCrow]

At the Ghostty level, no: you cannot simultaneously:

1. remove Ghostty’s shortcut,
2. keep Ctrl+Shift+P available to the child application, and
3. send no encoded input to the child.

Those requirements conflict with how terminal input works.

unbind means: remove Ghostty’s action and let the key continue to the program running inside the terminal. Ghostty’s documentation explicitly states that an unbound key is sent through to the child command. ignore, on the other hand, consumes the key and sends no encoding.

A terminal application does not receive a native GTK keyboard event such as “Ctrl+Shift+P.” It receives bytes through the PTY. Therefore, if Ghostty forwards that key while preserving the Ctrl+Shift distinction, it has to encode it as something such as a CSI-u sequence. There is no separate “forward the key but send zero bytes” mode: zero bytes means the child application received no key event.

So these are the two native Ghostty choices:

# Remove Ghostty's shortcut and forward the key to the child.
keybind = ctrl+shift+p=unbind

This may send a sequence such as:

ESC [ 112 ; 6 u

Or:

# Consume the key completely.
keybind = ctrl+shift+p=ignore

This sends nothing, but consequently terminal applications cannot use the shortcut.

However, if your actual requirement is:

Make Ctrl+Shift+P available to Flow, Neovim, or another terminal application, but do not display the sequence at an ordinary Bash prompt.

Then that is possible without using ignore, but it must be handled by Bash rather than Ghostty.

Keep:

keybind = ctrl+shift+p=unbind

Then configure Bash Readline to consume that specific sequence at the shell prompt.

First, determine the exact sequence Ghostty sends:

cat -v

Press Ctrl+Shift+P once, then exit with Ctrl+C.

For example, if the sequence is:

^[ [112;6u

where ^[ represents Escape, add this to ~/.inputrc:

$if Bash
"\e[112;6u": ""
$endif

Then reload the Readline configuration:

bind -f ~/.inputrc

GNU Readline supports binding an entire escape sequence to a macro; binding it to an empty macro causes Readline to consume it without inserting anything into the command line.

The resulting behavior is:

• At the Bash prompt: the sequence is received and silently consumed by Readline.
• Inside Flow, Neovim, tmux, or another full-screen terminal application: Bash is no longer reading input, so the application receives the original CSI-u sequence and can bind Ctrl+Shift+P.
• In applications that do not support CSI-u: the shortcut may still be ignored or displayed incorrectly, so those applications must also be configured appropriately.

Another possible workaround is to make Ghostty send a legacy control byte:

keybind = ctrl+shift+p=text:\x10

\x10 is the traditional encoding for Ctrl+P. This avoids the visible CSI-u sequence, but it is not equivalent to forwarding Ctrl+Shift+P: the application will see Ctrl+P, and the Shift distinction is lost.

Therefore, the precise answer is:

Ghostty alone cannot unbind the shortcut, forward the key, and emit no sequence. Forwarding a terminal key necessarily means sending bytes. Use ignore when the key must produce absolutely no input, or keep unbind and configure Bash/Readline to consume the sequence only at the shell prompt while allowing compatible terminal applications to receive it.