Good news: it's not you, and it's not your TUI. It's the terminal sitting between them.
Most terminal emulators have no way to tell apps that Shift was held down during Enter. When you press Shift+Enter, they helpfully send the exact same bytes as plain Enter — usually a carriage return — and the Shift bit just evaporates somewhere along the way.
So when something like elyra is listening for shift+enter, it's listening for a key event that will never arrive. As far as it knows, you only ever pressed Enter. So it does what you've told it to do when you press Enter.
Classic terminal stuff.
Alt+Enter — Option+Return on a Mac — sends a distinct escape sequence that pretty much every terminal forwards correctly. No config gymnastics required.
Create or edit ~/.elyra/agent/keybindings.json:
{
"tui.input.newLine": ["alt+enter", "shift+enter"]
}
Run /reload in elyra and you're done. Shift+Enter still works wherever it happens to work, and Alt+Enter picks up the slack everywhere else.
If you can't give up the muscle memory, you can configure your terminal to emit a proper escape sequence for Shift+Enter.
iTerm2: Settings → Profiles → Keys → Key Mappings → add a new mapping:
Keyboard Shortcut: ⇧↩
Action: Send Escape Sequence
Esc+: [13;2u
Ghostty / Kitty / WezTerm: Usually works out of the box. These terminals implement the kitty keyboard protocol, which handles modifier keys properly, so you shouldn't need to do anything.
macOS Terminal.app: Doesn't support it. If you're committed to Shift+Enter, consider this your nudge to switch to iTerm2 or Ghostty.
Just use Alt+Enter. Move on with your day. Sometimes the best fix is the one that's already working everywhere.
If you ever wondered why some keybindings feel mysteriously broken in some terminals but not others, this is usually the reason. The terminal is a layer, and not every layer carries every piece of information through. Once you know that, the workaround almost picks itself.