I noticed Ctrl+E does nothing when I'm inside an active Claude Code session. No error, no visual feedback, it just gets swallowed and forwarded straight to Claude. It happens 100% of the time on my machine (laptop keyboard, no numpad).
I tracked it down with kitty's own key inspector (kitty +kitten show_key -m kitty). When I press Ctrl+E I get:
ctrl+num_lock+e PRESS
CSI 101 ; 133 u
Modifier 133 is 1 (base) + 4 (ctrl) + 128 (num lock). My laptop has no physical numpad, but I guess the firmware still boots with the Num Lock state flag on internally (I think this is pretty common on laptops), and kitty's extended keyboard protocol faithfully reports that lock state as part of the modifier mask, per spec.
I looked at shortcutManager.js and getRawShortcutCodes() only ever generates the CSI-u variant with modifier 5 (ctrl-only, no locks), things like \x1b[101;5u, \x1b[69;5u, etc. Since the actual byte sequence I'm getting is ;133u and matchesRawInput does an exact/substring match against that precomputed list, it never matches, and the keypress just falls through to session.process.write(data).
I'd guess the same thing happens with Caps Lock on (+64) or both locks on (+192). Anyone whose OS or firmware happens to have Num Lock or Caps Lock toggled on is going to hit this for every Ctrl shortcut, silently, with zero indication of why. It's a pretty nasty one to debug from the user side since there's no error, the key just "doesn't work."
I think a possible fix would be, when parsing an incoming CSI-u sequence, to mask out the lock-state bits (64 for Caps Lock, 128 for Num Lock) from the modifier value before comparing, instead of requiring an exact match against a fixed set of pre-baked strings. I'm happy to test a patch if that's useful.
Repro:
- Have Num Lock on (I checked mine via
cat /sys/class/leds/*numlock*/brightness, or you can just toggle it since laptops without a numpad often default to this at boot and you'd never notice)
- Open a Claude Code session through ccmanager
- Press Ctrl+E, nothing happens
Environment:
- ccmanager 4.3.1 (both the
ccmanager package and @kodaikabasawa/ccmanager-linux-x64 binary)
- kitty 0.48.2
- Arch Linux (CachyOS), niri compositor
I noticed
Ctrl+Edoes nothing when I'm inside an active Claude Code session. No error, no visual feedback, it just gets swallowed and forwarded straight to Claude. It happens 100% of the time on my machine (laptop keyboard, no numpad).I tracked it down with kitty's own key inspector (
kitty +kitten show_key -m kitty). When I press Ctrl+E I get:Modifier
133is1 (base) + 4 (ctrl) + 128 (num lock). My laptop has no physical numpad, but I guess the firmware still boots with the Num Lock state flag on internally (I think this is pretty common on laptops), and kitty's extended keyboard protocol faithfully reports that lock state as part of the modifier mask, per spec.I looked at
shortcutManager.jsandgetRawShortcutCodes()only ever generates the CSI-u variant with modifier5(ctrl-only, no locks), things like\x1b[101;5u,\x1b[69;5u, etc. Since the actual byte sequence I'm getting is;133uandmatchesRawInputdoes an exact/substring match against that precomputed list, it never matches, and the keypress just falls through tosession.process.write(data).I'd guess the same thing happens with Caps Lock on (+64) or both locks on (+192). Anyone whose OS or firmware happens to have Num Lock or Caps Lock toggled on is going to hit this for every Ctrl shortcut, silently, with zero indication of why. It's a pretty nasty one to debug from the user side since there's no error, the key just "doesn't work."
I think a possible fix would be, when parsing an incoming CSI-u sequence, to mask out the lock-state bits (64 for Caps Lock, 128 for Num Lock) from the modifier value before comparing, instead of requiring an exact match against a fixed set of pre-baked strings. I'm happy to test a patch if that's useful.
Repro:
cat /sys/class/leds/*numlock*/brightness, or you can just toggle it since laptops without a numpad often default to this at boot and you'd never notice)Environment:
ccmanagerpackage and@kodaikabasawa/ccmanager-linux-x64binary)