Rebinding `enter` to `chat:newline` makes `chat:submit` silently fail while the autocomplete list is open

Environment

• Claude Code 2.1.233
• macOS (Darwin 25.6.0, arm64), iTerm2 3.6.11

Config

Using the keybindings.json from the accepted comment in #2054:

{
  "bindings": [
    {
      "context": "Chat",
      "bindings": {
        "enter": "chat:newline",
        "shift+enter": "chat:newline",
        "ctrl+enter": "chat:submit",
        "cmd+enter": "chat:submit"
      }
    }
  ]
}

Repro

1. Type /clear (or /resume) — the command autocomplete list appears.
2. Press ctrl+enter.

Expected

The command is submitted and runs.

Actual

Literally nothing happens. No error, no flicker; the input retains /clear.
The command can only be run by pressing Esc first (dismissing the list),
then ctrl+enter. Every slash command is affected, so with this config a
session cannot be cleared at all without knowing the Esc workaround.

Diagnosis

The fault is specific to chat:submit, not to keybinding dispatch:

• Other Chat-context actions dispatch fine while the list is open —

ctrl+g (chat:externalEditor) opens the editor as expected.

• Adding "ctrl+enter": "chat:submit" under an Autocomplete context

block does not help.

So the handler is registered and the key resolves; chat:submit's handler
appears to decline while a suggestion is pending. On a default install this
is invisible, because enter is serviced by the text-input widget's own
case "return" path — which accepts the pending completion and submits
together — and never invokes the chat:submit action at all.

Impact

This affects anyone using the enter → newline config from #2054, which is
the CJK-user audience the issue was opened for. Submit silently dies on
every slash command, with no feedback pointing at the cause.

Workaround

Esc, then ctrl+enter.