[VSCode] macOS Ctrl+F and Ctrl+P no longer work in chat input

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/21137

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Related issues — none were ever fixed; all closed silently by bot or deprioritized with no official comment:

| # | Topic | Surface | Status |
|---|---|---|---|
| #796 | Readline-compatible keybinding config | TUI | NOT_PLANNED |
| #2088 | Readline yank broken | TUI | NOT_PLANNED |
| #8177 | Broader macOS shortcuts broken | VSCode ext | NOT_PLANNED |
| #12358 | Cmd+H/Cmd+M hijacked by extension | VSCode ext | NOT_PLANNED |
| #18054 | Ctrl+B passthrough feature request | TUI | NOT_PLANNED |
| #20919 | Ctrl+P/N broken in chat input | TUI | bot-closed as dupe |
| #21137 | Ctrl+P/F broken in webview input | VSCode ext | bot-closed as dupe |

VSCode extension keyboard issues (#8177, #12358, #18054) have consistently been NOT_PLANNED. TUI readline issues (#796, #2088) got more engagement and were partially addressed over time.

Filed upstream: microsoft/vscode#320435 — root cause is workbench commands consuming Ctrl+F/Ctrl+P before the Cocoa text layer sees them.

Still reproduces on macOS as of 2026-06-25.

Environment:

• macOS 26.5 (25F71)
• VS Code 1.123.1
• Claude Code 2.1.152 (VS Code extension)

Ctrl+F (forward-char) and Ctrl+P (previous-line) are still swallowed in the Claude Code chat input, while the same native macOS Emacs-style bindings work everywhere else (Terminal, Safari, TextEdit). Notably, other readline-style keys in the same input — Ctrl+A (line start), Ctrl+E (line end), Ctrl+B (backward-char) — do work, so it is specifically Ctrl+F / Ctrl+P that get intercepted.

For reference: the earlier issue #21137 was closed as COMPLETED (2026-01-27), but the behavior has since regressed. The root cause appears to be tracked upstream at microsoft/vscode#320435 (workbench commands consuming Ctrl+F / Ctrl+P before the Cocoa text layer sees them).

+1 to keep this open — please don't auto-close it as a duplicate of an already-closed issue.

Still reproduces after both updating the extension and a full VS Code restart.

Environment:

• macOS 26.5.1 (25F80)
• VS Code 1.127.0
• Claude Code 2.1.198 (VS Code extension)

Ctrl+F and Ctrl+P still swallowed in chat input. Ctrl+A/E/B/N all work. Ruled out stale extension host / stale keybinding cache as the cause — full restart made no difference. Still consistent with the upstream root cause at microsoft/vscode#320435.

Still reproduces on the latest versions as of 2026-07-19.

Environment

• macOS 26.5.2 (25F84)
• VS Code 1.129.1
• Claude Code VS Code extension 2.1.215 (darwin-arm64), CLI 2.1.185
• claudeCode.useTerminal: false (webview UI), preferredLocation: panel

Same symptom split as reported above: Ctrl+A / Ctrl+E / Ctrl+B work, Ctrl+F and Ctrl+P are swallowed.

---

Evidence that contradicts the current root-cause theory

This thread states the cause is "workbench commands consuming Ctrl+F/Ctrl+P before the Cocoa text layer sees them." I don't think that's what is happening — at least not on this build.

With Developer: Toggle Keyboard Shortcuts Troubleshooting enabled and focus in the chat input, pressing Ctrl+F logs:

[KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: KeyF, keyCode: 70, key: f
[KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: KeyF, keyCode: 36 ('F')
[KeybindingService]: | Resolving ctrl+[KeyF]
[KeybindingService]: \ From 1 keybinding entries, no when clauses matched the context.

no when clauses matched means VS Code resolved the chord to no command and passed the event through. Nothing in the workbench consumed it.

For comparison, ArrowLeft — which does move the cursor — produces the same "no when clauses matched" outcome (14 entries, 0 matched). So the working key and the broken key take the identical path through KeybindingService. The difference must arise after that point.

The extension isn't intercepting it either. In webview/index.js (2.1.215), the only ctrlKey handler calling preventDefault() on a letter key is Ctrl+O. Every other ctrlKey reference is a !ctrlKey guard on Enter/Escape in dialogs.

That leaves the webview's own input component / Chromium's macOS text editing layer as where Ctrl+F and Ctrl+P are being lost — which would make this fixable in the extension rather than blocked on microsoft/vscode#320435.

Note on user-side workarounds: there are none. The extension contributes no cursor-movement commands (claude-vscode.* are all UI-level), so there is nothing for VS Code keybindings.json to bind to; and ~/.claude/keybindings.json applies to the terminal TUI, whose action list exposes no cursor-movement actions for the Chat context either.

Thanks @hsawano for the detailed investigation — this is very helpful.

I can confirm the same symptom split on my machine (Ctrl+A / Ctrl+E / Ctrl+B
work, Ctrl+F / Ctrl+P are swallowed):

macOS 26.5.2
VS Code 1.129.1 (Universal)
Claude Code extension <2.1.215> (darwin-arm64), webview UI
I also enabled "Developer: Toggle Keyboard Shortcuts Troubleshooting" and see
the same no when clauses matched log for Ctrl+F with focus in the chat
input, so I agree the workbench does not appear to be consuming these keys.

If the event reaches the webview untouched, this suggests the issue is in the
extension's input component (or Chromium's macOS text-editing layer inside the
webview) — i.e. fixable on the extension side without waiting on
microsoft/vscode#320435. Could the maintainers re-triage this issue in light
of the above? Happy to provide additional logs if useful.

@hsawano　さん
ありがとうございます

お恥ずかしながら，この問題の意味もよく理解できていない状況で，Claudeだのみでメールを差し上げております．
何卒よろしくお願い申し上げます．

スキルヴィズ
https://skill-vis.com
太田　憲 Ken Ohta, Ph.D.

2026/07/19 23:00、Hiroaki SAWANO @.***>のメール: hsawano left a comment (anthropics/claude-code#66291) <https://github.com/anthropics/claude-code/issues/66291#issuecomment-5015995447> Still reproduces on the latest versions as of 2026-07-19. Environment macOS 26.5.2 (25F84) VS Code 1.129.1 Claude Code VS Code extension 2.1.215 (darwin-arm64), CLI 2.1.185 claudeCode.useTerminal: false (webview UI), preferredLocation: panel Same symptom split as reported above: Ctrl+A / Ctrl+E / Ctrl+B work, Ctrl+F and Ctrl+P are swallowed. Evidence that contradicts the current root-cause theory This thread states the cause is "workbench commands consuming Ctrl+F/Ctrl+P before the Cocoa text layer sees them." I don't think that's what is happening — at least not on this build. With Developer: Toggle Keyboard Shortcuts Troubleshooting enabled and focus in the chat input, pressing Ctrl+F logs: [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: KeyF, keyCode: 70, key: f [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: KeyF, keyCode: 36 ('F') [KeybindingService]: | Resolving ctrl+[KeyF] [KeybindingService]: \ From 1 keybinding entries, no when clauses matched the context. no when clauses matched means VS Code resolved the chord to no command and passed the event through. Nothing in the workbench consumed it. For comparison, ArrowLeft — which does move the cursor — produces the same "no when clauses matched" outcome (14 entries, 0 matched). So the working key and the broken key take the identical path through KeybindingService. The difference must arise after that point. The extension isn't intercepting it either. In webview/index.js (2.1.215), the only ctrlKey handler calling preventDefault() on a letter key is Ctrl+O. Every other ctrlKey reference is a !ctrlKey guard on Enter/Escape in dialogs. That leaves the webview's own input component / Chromium's macOS text editing layer as where Ctrl+F and Ctrl+P are being lost — which would make this fixable in the extension rather than blocked on microsoft/vscode#320435 <https://github.com/microsoft/vscode/issues/320435>. Note on user-side workarounds: there are none. The extension contributes no cursor-movement commands (claude-vscode.* are all UI-level), so there is nothing for VS Code keybindings.json to bind to; and ~/.claude/keybindings.json applies to the terminal TUI, whose action list exposes no cursor-movement actions for the Chat context either. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/66291?email_source=notifications&email_token=BQY2M6ZPJJXVEDONKHIGHDT5FTH6RA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBRGU4TSNJUGQ32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5015995447>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BQY2M6ZSH2EXZBT4RYEZCDL5FTH6RAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINRRGQZDCMBRGAZ2C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BQY2M646RWXK5TB7IQZCBED5FTH6RA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBRGU4TSNJUGQ32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BQY2M64SZAYMHFPSI3KMGWL5FTH6RA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBRGU4TSNJUGQ32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.