/mulmoterminal-keys

name: mulmoterminal-keys
description: Bind keyboard shortcuts and fix keyboard/clipboard behaviour in MulmoTerminal. **Writes `keymap`** — Settings → Keyboard shortcuts also sets or clears ONE action's key by pressing it (single keystrokes; a two-key sequence and the `send` list are still written here), and its Recommended keys block adds this platform's starter set. **Explains `copyOnSelect`, `questionPaneEnabled`, `terminalSubmit` and `tmuxPrefix`**, which have their own Settings controls under Terminal keys — point the user at those, and write the key yourself only when they have no browser to hand. Covers zooming a cell, jumping to whichever agent is waiting for you, opening and closing terminals, copy/paste, sending raw bytes to the terminal so a key the shell understands can be reached from a key your keyboard has (Cmd+Right for end-of-line), copying by selecting with no key pressed, and the Enter-vs-newline binding. Use when the user wants a shortcut or hotkey, wants to switch cells or reach a waiting agent without the mouse, wants selecting text to copy it, or reports that Shift+Enter submits their prompt instead of adding a line, that Enter drops to a new line instead of sending, that Ctrl+C stopped interrupting, that a shortcut does nothing, or that on a Mac Cmd+Left / Cmd+Right / Cmd+Delete behave as though the Cmd were ignored — moving or deleting one character, the same as the unmodified key.

Keyboard, shortcuts and clipboard

These settings all live in **`~/.mulmoterminal/config.json`**, and each write is a **partial `POST /api/config` merge** — write only the key you are changing, so the user's other settings survive.

**"Partial" means per TOP-LEVEL key, and `keymap` is replaced WHOLE.** The merge is `body[key] !== undefined ? sanitize(body[key]) : current` (`server/config/app-config.ts`), so posting

{ "keymap": { "send": [ … ] } }

does not add a `send` to the keymap — it **makes that the entire keymap**, deleting every action binding the user had. Nothing warns, and the reply is a success.

So a keymap write always sends the **complete** keymap: what step 1 read, plus the change. Read it, merge in memory, post the whole thing. An entry naming an action this version does not know (a typo like `zoom-toogle`, or a newer release's action) is kept in the file whatever you post, including when you leave it out (`GET /api/config` does not return it) — to remove one, edit `config.json` directly. Every `keymap` example below shows one setting on its own for readability — none of them is a body to post as-is unless the user genuinely has nothing else bound.

Settings has a **Keyboard shortcuts** section: every action and its current binding, plus a `send` row (one per configured entry, or a single "Not set" placeholder). Each action row has **Change**, which records the next keystroke pressed and saves it at once (a single keystroke — a two-key sequence and the `send` list are still written here), and **Clear**. A binding that would stop the server from starting is refused there, and one the browser keeps is saved with a warning. Point the user at it after writing, as the check — or at Change, when all they want is one single-key shortcut. Below the list, **Recommended keys** adds this browser's platform's starter set (Mac: the Up/Down pair of Arrows plus the macOS line-editing `send` set; Windows/Linux: all four Arrows) in one click — only to actions that are unbound and keys nothing starts with, so it never replaces a binding. Anything beyond that set, or a different key, is still this skill's job.

Open with a proposal, not a question — **on the keymap path only**

**First, check which path you are on.** This skill answers two different arrivals, and the flow below belongs to one of them:

| the user said | go to | |---|---| | nothing specific, or arrived via **Set up shortcuts…** | this section | | "selecting text doesn't copy" | [`copyOnSelect`](#copyonselect--copy-just-by-selecting) | | anything about the question pane | [`questionPaneEnabled`](#questionpaneenabled--answer-a-question-from-a-side-pane) | | "Shift+Enter submits", "Enter makes a newline" | [`terminalSubmit`](#terminalsubmit--enter-vs-newline) | | "Ctrl+B does nothing / needs two presses", "the next key after Ctrl+B is eaten" | [`tmuxPrefix`](#tmuxprefix--the-tmux-prefix-key) | | "Ctrl+C stopped interrupting" | **the diagnostic below — not this section, and not `terminalSubmit`** |

"Ctrl+C stopped interrupting" — diagnose, do not propose

**Skip the proposal flow entirely.** This user has one binding too many, not too few; offering them a starter set would add more keys taken from the terminal, which the rule below forbids. The job is to find the claim, show it, and remove or move it once they agree.

Read the whole keymap and find **everything** claiming that keystroke, not just one entry:

| what is on `Ctrl+C` | what it does to the interrupt | |---|---| | an action other than `copy` / `paste` | takes it **always** — the grid claims the key in the capture phase before the terminal sees it | | `paste` | takes it **always** — not through the grid (`gridShortcutFor` skips terminal-scoped actions) but inside the terminal, ahead of `send` | | `copy` | takes it **only while something is selected** — `clipboardActionFor` returns null with no selection, so the key falls through | | a `send` entry | replaces it with those bytes — **and it is what fires** when `copy` is on the same key with nothing selected |

So "it works sometimes" points at `copy` plus a selection sitting in that cell, and "it never works" points at one of the others. `terminalSubmit` is not involved either way, and changing it would be debugging the wrong setting.

Report every claim you found, say which one explains what they are seeing, and change **only that one** — after they confirm. Remember the whole-keymap write rule above: post the complete map with that single entry removed or moved, never a map containing