Custom Chat-context `enter` keybinding makes footer items unopenable (shadows Footer's default `enter` / footer:openSelected)

Environment

• Claude Code v2.1.199, terminal CLI (native install, Linux x86_64, Ubuntu)
• Reproduced identically under tmux (xterm-256color) and Terminator (VTE), so this is in-app key dispatch, not terminal-emulator key translation
• Using ~/.claude/keybindings.json (the customization feature added in v2.1.18+)

Summary

If a user remaps enter inside the Chat context (for example the Enter/submit swap suggested in the terminal config docs), footer task chips become unopenable by keyboard: selecting a background task chip and pressing Enter inserts a newline into the composer instead of firing footer:openSelected. The chip stays selected. No keybindings.json arrangement restores it, including an explicit user Footer binding for enter.

With default keybindings, enter is the default key for footer:openSelected in the Footer context, so this works out of the box. The regression requires nothing beyond a Chat-scoped user binding; the user never touches the Footer context.

Minimal repro config

{
  "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
  "bindings": [
    {
      "context": "Chat",
      "bindings": {
        "enter": "chat:newline",
        "alt+enter": "chat:submit"
      }
    }
  ]
}

Adding an explicit Footer block changes nothing:

    {
      "context": "Footer",
      "bindings": {
        "enter": "footer:openSelected"
      }
    }

Steps to reproduce

1. Install the keybindings above.
2. Start claude and have it launch a background Bash task (run_in_background: true), so a task chip appears in the footer status row.
3. With the composer empty, press Down. The chip gets selected (reverse-video highlight).
4. Press Enter.

Expected: the selected item opens (footer:openSelected, matching both the Footer default and the explicit user Footer binding).

Actual: a newline is inserted into the composer (chat:newline fires) and the chip remains selected.

This reproduces 100% when scripted (tmux send-keys for input, capture-pane -e to verify the selection highlight and the composer growing an extra line).

Ruled out

• File order of the binding blocks: all orderings tested, no change.
• Explicit "Footer": {"enter": "footer:openSelected"} user binding: ignored in this state.
• Binding footer:openSelected to a different chord in the Chat context (e.g. alt+o): the action does not dispatch (0/3 scripted trials).
• Terminal emulator differences: identical behavior under tmux/xterm-256color and Terminator.

Notably, arrow keys keep working while a chip is selected (they are not bound in Chat, so they fall through to footer navigation), and once the Background panel is actually open, its own keys including Enter work fine. The break is limited to the inline chip-selection state while the composer has focus.

Root-cause pointers (from reading the shipped v2.1.199 binary)

The bundled default binding table confirms enter is the sole default for footer:openSelected in context "Footer" (a [{context, bindings}] array embedded in the executable).

The legacy key resolver collects candidate bindings from all simultaneously active contexts by Set membership (context order is discarded: the contexts argument is only used as new Set(t) for filtering) and returns the last match in a flat merged bindings array. That array is built as [...defaults, ...userKeybindings], with user entries appended last. The chat submit/newline handlers contain no footer-awareness, and the footer chip row registers plain enter through the same generic context-handler API as everything else, so the outcome is decided purely by this resolution order.

Net effect: a single-context user override for a chord can shadow unrelated contexts' defaults for that same chord whenever several contexts are active at once, and in the composer-focused chip-selected state the Chat binding consistently wins regardless of how the user file is arranged.

Expected behavior

User bindings should shadow only within their declared context. When a footer chip is selected and both Chat and Footer are active for key routing, the Footer enter binding (default or user-supplied) should win for that keystroke.

Impact

Anyone using the documented Enter/newline swap (or any Chat-context enter remap) silently loses keyboard activation of background task, agent, and monitor chips in the footer.