[BUG] Custom keybindings in Chat context silently ignored since v2.1.105–2.1.107 (regression from 2.1.104)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
Custom keybindings defined in ~/.claude/keybindings.json for the Chat context are silently ignored starting in v2.1.105–2.1.107. The binding itself is still parsed (file is valid and was untouched across upgrades), but the bound action never fires.
Specifically: "ctrl+/": "voice:pushToTalk" worked reliably on v2.1.104 and stopped firing by v2.1.107. Default Space push-to-talk still works, confirming voice itself is functional — only custom bindings are broken.
Tested with an alternate chord (ctrl+.) to rule out Ctrl+/ parsing — also ignored. So the regression is the custom keybinding dispatch, not any specific key combo.
What Should Happen?
Pressing Ctrl+/ (or any configured custom binding) in the Chat context should invoke the bound action — in this case voice:pushToTalk.
Steps to Reproduce
- Create \
~/.claude/keybindings.json\:
\\\json\
{
"bindings": [
{
"context": "Chat",
"bindings": {
"ctrl+/": "voice:pushToTalk"
}
}
]
}
\\
- Start Claude Code on v2.1.104 → Ctrl+/ activates voice push-to-talk.
- Upgrade to v2.1.107+ → Ctrl+/ does nothing. Default Space still works.
Last Working Version
2.1.104
Claude Code Version
2.1.107+ (broken; did not test 2.1.105/2.1.106 individually, but changelog shows terminal key-encoding work landed in 2.1.105 which is a plausible culprit)
Platform
Anthropic API
Operating System
Linux (Fedora 43, kernel 6.19.11)
Terminal/Shell
bash
Additional Information
- Possibly related: #48023 (keybindings.json custom actions ignored on v2.1.89, macOS) — same symptom class, different version/platform, may share a root cause or be a re-regression after a fix.
- Precedents for silent default-binding changes in recent versions: #45364 (v2.1.94, Ctrl+L), #49317 (v2.1.111, Ctrl+W/Ctrl+U).
- Changelog note: v2.1.105 included fixes to \
alt+enter\(ESC-prefix alt encoding) and \Ctrl+J\newline handling — likely the same area of code.
9 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Custom keybindings in Chat context silently ignored since v2.1.105-2.1.107 is a capability regression — keybindings are a power-user feature that enables significantly more efficient workflows, and silent failure (keybinding appears configured but does not work) is the worst failure mode: the user has no indication that their configuration is being ignored.
This is part of a broader pattern of VS Code extension configuration silently not applying (#49851 Stop hooks, #49063 UserPromptSubmit, #49937 SessionStart source). The VS Code extension appears to have introduced multiple config-application gaps in the 2.1.100+ version range.
The regression boundary (2.1.104 good, 2.1.105-2.1.107 broken) is useful for narrowing the root cause: a specific change in that version range broke keybinding registration in the Chat context. The Chat context specifically (as opposed to other contexts) suggests a context-scoped registration issue — keybindings for other contexts may still work.
Diagnostic steps:
Ctrl+K Ctrl+S(VS Code keyboard shortcuts) to see whether the custom bindings are shown as activewhenclause that may have changed the context conditionThe fix should be in the Chat context's keybinding registration: whatever context key identifies "Chat is focused and active" may have changed names in 2.1.105, causing custom keybindings with that context condition to never fire.
ah! This is why my Ctrl+Up hasn't been listening for my voice instructions! I've been reduced to typing.
Not sure it's a duplicate, but the referenced "possible duplicate" issue says that their affected version is "2.1.89". Because voice/keybind functionality was fine for me in 2.1.104, I can only hope it's not a bug that keeps reappearing.
For me the "hold space to speak" functionality works, but I don't really want it to. I, just like you, just want my custom keybind (which in turn should _disable_ the space bar detection logic).
The 'hold space bar' logic of Claude gets in the way of my local voice transcription model, due to the latter's rapid insertion of spaces.
Looking into this — keybindings in Chat context regressed between v2.1.104 and v2.1.105. Happy to submit a fix.
Looking into this — the Chat context keybinding handler likely has a regression that filters out custom bindings. I'll submit a fix.
@bobo-xxx @qing-ant or whoever fixed it
Thank you!
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.