[BUG] Using shift+Enter in Ghostty sends `[27;2;13~` which isn't interpreted to insert a newline

For context, I'm on macOS, and recently switched from iTerm to Ghostty.

When running claude in iTerm, pressing Shift+Enter sends \n, and Claude correctly inserts a line break.
When running claude in Ghostty, pressing Shift+Enter sends the [27;2;13~ escape sequence instead. Here Claude does not insert a line break, but instead pastes the text [27;2;13~ verbatim in the input. This is the bug.

Claude Code's own verdict

Perfect! This shows exactly what's happening. iTerm sends a simple \n for Shift+Enter, while Ghostty sends the more complex escape sequence [27;2;13~. This is actually Ghostty following a newer terminal standard (modifyOtherKeys) that provides more precise key information. The escape sequence breaks down as: - [27;2;13~ = modifier(2=Shift) + key(13=Enter) Ideally Claude Code should recognize this standard escape sequence. This is a legitimate compatibility issue where: 1. Ghostty is correctly implementing the modifyOtherKeys protocol 2. Claude Code only recognizes the older, simpler format I'd recommend filing this as a bug report with Claude Code since they should support the modern terminal standard that Ghostty uses. The issue title could be something like "Support modifyOtherKeys escape sequences for Shift+Enter in Ghostty terminal".

Workaround

Since switching to Ghostty, I've instead started using alt+Enter instead, which also works to insert a line break as a workaround, but ideally both should work.