# How keys work (/docs/v0.1/keybindings) A koshi shortcut is a **sequence** of chords, not a single chord. The default leader is Ctrl, so ` l` means "hold Ctrl and press p, release, then press l". ## Pending sequences [#pending-sequences] Once you press the first chord, koshi holds the sequence open. The hint bar at the bottom lists what the next key can be, and the chords you already pressed are marked with the theme's `accent` colour. While a sequence is open, keys go to koshi — not to the program in the pane — until the sequence completes or you cancel it with Esc. A key that matches no continuation is discarded and leaves the sequence open. Prefix-only sequences have no timeout. `chord-timeout-ms` applies only when the same sequence is both a complete binding and the prefix of a longer one. At that ambiguity deadline, koshi fires the complete binding. ## Modes [#modes] Bindings live in modes. Locked input is a mode of its own: with \ every key goes straight to the focused program, which is how you use a program that wants the same chords koshi does. ## Inspecting the live keymap [#inspecting-the-live-keymap] ```bash koshi keys list # active shortcuts koshi keys list --mode koshi keys list --scope user # only what your config added koshi keys describe " l" # what it does and where it came from ``` ## Conflicts [#conflicts] ```bash koshi keys conflicts ``` Reports clashes, sequences made unreachable by a shorter prefix, and warnings. Run it after editing `keybinding.kdl` — a shortcut hidden behind a prefix never fires, and nothing else tells you. Validate a file before adopting it: ```bash koshi keys validate path/to/keybinding.kdl ``` `keybinding.kdl` is all-or-nothing. One error drops the whole file and koshi falls back to the defaults, unlike `koshi.kdl` where a bad field only loses that field. ## Next [#next]