[FEATURE] Let a plugin give its pane's Client the keyboard without a mouse click

Status Open
Reported on v2.1.296
Maintainer reply None cached
Activity 0 comments · opened Oct 14, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

A plugin pane that draws its list in a Client only gets keys after the user clicks it. When the pane takes the keyboard without a click (ctrl+x tab, $.ui.open({ focus: true }), a command: keybinding), the focus ring can only land on a Button, Input or Select, and $.ui.focus accepts only those.

The workaround is an autoFocus Input that relays typed characters to the Client. A focused Input keeps ← and → for its own caret and raises nothing for them, so a pane opened from the keyboard can't use the side arrows (in my case, expand and collapse folders in a tree) until the user clicks into it. The hidden Input also puts the terminal cursor somewhere in or near the pane.

Proposed Solution

Let $.ui.focus({ requestId, key }) accept a Client's key and give that instance the keys the way a click does: its onKey receives every key until Escape returns focus to the prompt. An autoFocus prop on Client would cover the same case.

Alternative Solutions

  • An onKey on Input, or a ui.input event for caret moves that carries the key, so the relay field can pass ← and → on.
  • ui.scroll reporting left and right in a focused pane, as it does for up and down.

What I tried: with the ring on a blank Button, ← and → never reach the pane (no ui.focus, ui.press or ui.scroll). Pane-context keybindings to command: do fire there, but only while a Button holds the ring, they apply to every plugin's pane, and Button hotkeys can't tell shift. Routing every key that way drops or misreads keys typed in quick succession while the ring moves to a search Input. prompt.edit doesn't report ↑ ↓, or ← and Backspace in an empty composer.

Today I use Enter and Backspace as stand-ins for → and ← when the pane was focused from the keyboard, and the pane's border says so.

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

  1. Bind ctrl+x l to a command that opens a file-tree pane with focus: true.
  2. Press ↓ to reach a folder, then → to expand it.
  3. ↓ works, but → moves the hidden Input's caret. The user has to click the pane before the side arrows work.

Additional Context

Claude Code 2.1.296, macOS, Ghostty, fullscreen.

View original on GitHub ↗