[Feature] Support stateful key actions in extension selectors

[mulatta]

Area

Coding agent and CLI, TUI

Problem

Daemon-backed extensions can use ctx.ui.select(), but the selector only supports up/down navigation, Enter to confirm, and Escape to cancel.

This limits extensions that build stateful or multi-step selection flows. For example, an extension may need to:

• toggle the highlighted item without closing the logical flow;
• redraw options after changing selection state;
• move backward or forward between related views;
• preserve the highlighted row after a redraw; or
• provide keyboard shortcuts alongside visible fallback actions.

Extensions cannot implement these behaviors directly. Daemon workers do not receive raw terminal input, and executable UI callbacks cannot cross the daemon/client boundary.

An extension can emulate these flows with repeated one-shot selectors and visible action rows, but every action requires Enter and every redraw resets the highlighted row.

Proposed direction

Extend the existing serializable select options with optional state and key actions.

For example:

interface ExtensionUISelectKeyActions {
  space?: "select";
  left?: string;
  right?: string;
  tab?: string;
  shiftTab?: string;
}

interface ExtensionUISelectOptions extends ExtensionUIDialogOptions {
  initialIndex?: number;
  keyActions?: ExtensionUISelectKeyActions;
}

Proposed behavior:

• space: "select" returns the currently highlighted option through the normal
  select response.
• Navigation keys return the configured string value.
• initialIndex sets the highlighted row when the selector opens.
• The interactive client validates and allowlists all serialized fields.
• Existing up/down, Enter, and Escape behavior remains unchanged.
• Existing response shape remains { value: string }.

This keeps application state in the extension. Core only maps a small, declarative set of keys to existing selector results. It does not transport raw key events or executable callbacks across the daemon boundary.

All fields are optional and additive. Older clients can ignore them. Extensions can retain visible action rows as a compatible fallback.

Alternatives considered

1. Visible action rows only

Extensions can include Back, Next, Apply, or Done rows and require Enter to activate them. This works with existing clients but provides no direct keyboard actions and resets the cursor after every redraw.

2. Change the global select confirmation binding

Binding Space globally would affect unrelated selectors and text-entry flows. It also would not provide per-dialog navigation actions or cursor restoration.

3. Add specialized protocol methods for each stateful UI

Dedicated methods for multi-select lists, paginated pickers, wizards, and other flows would duplicate protocol and client logic. Generic selector options cover these cases with a smaller API.

4. Forward raw terminal input to daemon extensions

This creates a much broader protocol, ownership, and security surface. A fixed allowlist of declarative key actions is narrower and easier to validate.

5. Add client-local UI extensions

This could support fully custom interactive components, as discussed in #1462, but it is substantially larger than extending the existing serializable selector.

Additional context

Related discussions:

• Support client-local UI extensions in daemon-backed interactive chats #1462 — client-local UI extensions in daemon-backed chats
• [Bug] Extension shortcuts never register in daemon-backed interactive chats (shift+tab effort-cycle) #1516 — extension shortcuts not registering in daemon-backed chats
• Extension UI in daemon/RPC mode: setWidget component factories silently dropped, worker theme uninitialized, no terminal width available #2065 — remaining daemon/RPC extension UI gaps

Current ExtensionSelectorComponent.handleInput() on main handles only up/down, confirm, and cancel. I did not find an existing Discussion, Issue, or pull request covering per-selector key actions or initial selection state.

If this direction fits the project roadmap, I can prepare a focused pull request with tests for:

• initial-index validation and clamping;
• Space selecting the highlighted option;
• Left/Right/Tab/Shift+Tab returning configured actions;
• daemon and RPC payload forwarding;
• malformed payload rejection; and
• unchanged behavior when optional fields are absent.