Repository navigation
Korean IME: All Ctrl+key shortcuts silently ignored when Hangul input is active #40291
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
When the Korean (Hangul) IME is active, all Ctrl+key shortcuts are completely non-functional in Claude Code. This includes Ctrl+C, Ctrl+A, Ctrl+L, Ctrl+E, and every other Ctrl combination. Switching to English input mode immediately restores all shortcuts.
This is not a system-wide or terminal issue — the same shortcuts work perfectly in:
- Terminal.app (bare shell)
- iTerm2
- tmux
The problem only occurs inside Claude Code's TUI.
What Should Happen?
Ctrl+key shortcuts should work regardless of the active input source, as they do in standard terminal applications. Terminal emulators pass Ctrl+key as raw control characters (e.g., Ctrl+C = 0x03) independent of IME state.
Error Messages/Logs
No error messages — the shortcuts are silently ignored with no feedback.
Steps to Reproduce
- Open Claude Code in any terminal (Terminal.app, iTerm2, etc.)
- Switch macOS input source to Korean (한국어)
- Try any Ctrl+key shortcut:
Ctrl+C— Expected: interrupt/cancel → Actual: nothingCtrl+A— Expected: cursor to line start → Actual: nothingCtrl+L— Expected: clear screen → Actual: nothingCtrl+E— Expected: cursor to line end → Actual: nothing
- Switch input source back to English
- All shortcuts work again
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Claude Code Version
2.1.86 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
- Terminal used: cmux (Ghostty/libghostty-based macOS terminal)
- Also tested in Terminal.app, iTerm2 — same behavior in all terminals.
Workaround: Using Karabiner-Elements to intercept Ctrl+key at the OS level — temporarily switching to English, sending the shortcut, then switching back to Korean. This is an OS-level hack, not a proper fix — the issue should be resolved in Claude Code's input handling layer.
Activity
github-actions commentedon Mar 28, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
pereng11 commentedon Mar 28, 2026
Not a duplicate — here's why
The three suggested duplicates are related but distinct:
#36549 — Ctrl shortcuts fail on non-Latin keyboard layouts (Kitty-specific)
#27859 (CLOSED) — Shortcuts don't work with non-Latin layouts
#19704 (CLOSED) — Ctrl+C/U/V not working with Russian layout
What makes this issue worth keeping open
I've added a comment to #36549 linking back here. These issues should be tracked together but not merged, as the fix for Kitty protocol may not resolve the Terminal.app/iTerm2 case.
Workaround
Using Karabiner-Elements to intercept Ctrl+key at the OS level — temporarily switching to English, sending the shortcut, then switching back to Korean:
bash <(curl -fsSL https://raw.githubusercontent.com/pereng11/karabiner-korean-shortcuts/main/install.sh)Source: https://github.com/pereng11/karabiner-korean-shortcuts
github-actions commentedon Apr 28, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon May 8, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.