[Bug] Escape key closes /btw modal and unintentionally rejects pending file edits

This makes /btw unusable for me. Everytime I hit ESC on a /btw screen, it also interrupts the main agent

A bit annoying to ask then Claude what did I just cancel

Confirming this still reproduces on Linux and on a much newer build, so it's cross-platform and not yet fixed (both earlier reports were macOS on 2.1.152/2.1.158).

Environment

• Platform: linux
• Terminal: xterm-256color
• Version: 2.1.193

Repro

1. Run /btw and ask something.
2. While the /btw view is open, the main agent surfaces a confirmation prompt (e.g. a permission/file-edit dialog, or an AskUserQuestion).
3. The /btw modal shows "Esc to close", so I press Esc to dismiss just the /btw view.
4. The Esc leaks through to the layer underneath and cancels/rejects the pending confirmation instead of only closing /btw.

Expected: Esc should be captured by the topmost layer (the /btw modal) and only close that — the underlying confirmation should stay pending until I explicitly act on it.

Impact: as others noted, this effectively makes /btw unsafe to dismiss whenever the main agent has a prompt waiting — you can silently reject an edit/permission you wanted to approve, with no way to tell what was cancelled.

This looks like the same class as the already-fixed _"pressing Escape in the AskUserQuestion notes field aborting the turn instead of returning to answer selection"_ — Esc routing to the wrong layer.

Still an issue

Still reproduces on 2.1.220 (macOS 24.6.0, arm64, fullscreen TUI), and the behavior has changed for the worse since the earlier reports here.

New shape: the panel doesn't close at all

Earlier reports describe Esc closing /btw and leaking through to cancel the layer underneath. On 2.1.220, with an AskUserQuestion dialog pending:

1. A skill/agent turn calls AskUserQuestion; the picker is on screen awaiting an answer.
2. Submit /btw <side question>; the panel renders and answers.
3. Press Esc.
4. The /btw panel stays open. Only the pending AskUserQuestion is cancelled, aborting the interview.

So it is no longer "Esc does two things" — the /btw panel appears to receive no key input at all while the dialog is pending, and every keystroke goes to the dialog underneath. The user is left with an interview destroyed and a panel they still can't dismiss.

Root cause, from a static read of the 2.1.220 bundle

(Symbols are minified, so this is described by behavior rather than by name. BUILD_TIME 2026-07-24T22:17:45Z, GIT_SHA 4073f59596e272f39393db4f96abc5f4b10eff21.)

• /btw is registered as {type: "local-jsx", name: "btw", immediate: true} and its panel is rendered into the same setToolJSX overlay slot used by tool-driven blocking dialogs such as AskUserQuestion.
• The /btw panel's key handler binds escape / return / space / ctrl+c / ctrl+d to one shared close path (onDone(undefined, {display: "skip"})), plus ←/→ history nav, ↑/↓ (ctrl+p/n) scroll, c copy, x clear history, f fork.
• The AskUserQuestion dialog handler independently binds escape → preventDefault() + cancel.
• Both handlers call preventDefault(), so whichever the dispatcher reaches first wins outright. Inference, not verified: with both mounted, dispatch reaches the question dialog first, which is why the panel's handler never fires on 2.1.220.

Not workaroundable via keybindings.json

The valid keybinding contexts are Global, Chat, Autocomplete, Confirmation, Help, Transcript, HistorySearch, Task, ThemePicker, Settings, Tabs, Attachments, Footer, MessageSelector, DiffDialog, DiffPanel, ModelPicker, Select, Plugin. There is no side-question/btw context — the panel uses its own raw handler instead of the keybinding registry, so users can't rebind their way out of this.

Partial user workaround (with a sharp edge)

Since return and space hit the same close path as escape, they can close the panel once it actually has focus — e.g. after the underlying dialog is already gone. But while the dialog is still stealing input, Enter selects the focused option and Space toggles it in multi-select, so both risk silently submitting a wrong answer. There is currently no safe key.

Suggested fixes

• Refuse to open /btw while a blocking tool dialog owns the setToolJSX slot (clear message, or queue it until the dialog is answered); or
• Give the topmost overlay exclusive key focus, so /btw consumes Esc while open and the dialog underneath stays pending.

Also worth noting for triage: #74959 and #64568 look like the same defect from different angles.