Shift+Enter is intercepted and not forwarded to the PTY
Summary
Superset's terminal intercepts Shift+Enter via attachCustomKeyEventHandler and prevents it from reaching the PTY. This breaks terminal applications that rely on the Kitty keyboard protocol to distinguish Shift+Enter from plain Enter — notably pi, Claude Code, and other CLI tools that use Shift+Enter for multi-line input.
Expected behavior
When a terminal application has enabled the Kitty keyboard protocol (via CSI > 1 u), Shift+Enter should be forwarded to the PTY as the CSI u sequence \x1b[13;2u, allowing the application to distinguish it from plain Enter.
Actual behavior
Shift+Enter is unconditionally swallowed by Superset's custom key event handler:
// helpers.ts ~line 536
const isShiftEnter =
event.key === "Enter" &&
event.shiftKey &&
!event.metaKey &&
!event.ctrlKey &&
!event.altKey;
if (isShiftEnter) {
if (event.type === "keydown" && options.onShiftEnter) {
event.preventDefault();
options.onShiftEnter();
}
return false; // ← prevents xterm.js from sending anything to the PTY
}The return false prevents xterm.js from processing the key, so the Kitty protocol response is never generated regardless of whether the application requested it.
Affected applications
- pi — uses Shift+Enter for new line in its TUI editor
- Claude Code — uses Shift+Enter for multi-line input
- Any terminal application using the Kitty keyboard protocol
Suggested fix
Check whether the Kitty keyboard protocol is active before intercepting. xterm.js tracks this internally. When the protocol is enabled, Shift+Enter should pass through to the PTY so xterm.js can encode it as \x1b[13;2u.
A simpler alternative: add a per-terminal or global setting to disable the Shift+Enter interception, e.g.:
{
"terminal.shiftEnterBehavior": "passthrough" | "superset"
}Workaround
Users can rebind the new-line action in pi to Ctrl+J via ~/.pi/agent/keybindings.json:
{
"tui.input.newLine": ["shift+enter", "ctrl+j"]
}Environment
- Superset: latest
- macOS
- pi / Claude Code running inside Superset terminal
Shift+Enter is intercepted and not forwarded to the PTY
Summary
Superset's terminal intercepts Shift+Enter via
attachCustomKeyEventHandlerand prevents it from reaching the PTY. This breaks terminal applications that rely on the Kitty keyboard protocol to distinguish Shift+Enter from plain Enter — notably pi, Claude Code, and other CLI tools that use Shift+Enter for multi-line input.Expected behavior
When a terminal application has enabled the Kitty keyboard protocol (via
CSI > 1 u), Shift+Enter should be forwarded to the PTY as the CSI u sequence\x1b[13;2u, allowing the application to distinguish it from plain Enter.Actual behavior
Shift+Enter is unconditionally swallowed by Superset's custom key event handler:
The
return falseprevents xterm.js from processing the key, so the Kitty protocol response is never generated regardless of whether the application requested it.Affected applications
Suggested fix
Check whether the Kitty keyboard protocol is active before intercepting. xterm.js tracks this internally. When the protocol is enabled, Shift+Enter should pass through to the PTY so xterm.js can encode it as
\x1b[13;2u.A simpler alternative: add a per-terminal or global setting to disable the Shift+Enter interception, e.g.:
{ "terminal.shiftEnterBehavior": "passthrough" | "superset" }Workaround
Users can rebind the new-line action in pi to Ctrl+J via
~/.pi/agent/keybindings.json:{ "tui.input.newLine": ["shift+enter", "ctrl+j"] }Environment