[BUG] Pressing Esc to exit /btw mode rejects the pending tool-use prompt instead of just exiting the mode

Commenting to keep this bug report on Anthropic's radar.

Upvote if you are reading this and have the problem described

I noticed this behavior occurred for me after the introduction of the fullscreen tui. Try doing a "/tui default" and see if that resolves for you (it did for me).

we need this fix 🤓

I'm switching from claude code to goose. (Note Anthropic is part of the AAIF, so they shouldn't be too mad about it.) But probably going to be paying less attention to claude code bugs now. If there's a bug in goose, I can fix it myself.

I have noticed this behavior on Mac, Windows, and Raspberry PI both natively and via SSH sessions. Please pick something else to switch from or close the btw session. It's a great feature! But as is, unusable.

Any news on this bug? It's really annoying and open for quite a while
I'm on Mac, ghostty, claude code v2.1.212

ping

Still reproduces on 2.1.227 (macOS, "tui": "fullscreen"), and nothing in the 2.1.228 changelog touches this — so it has survived ~2.5 months. (I have not tested @tekstrong's /tui default workaround, so I can't confirm or rule it out.)

One detail that hasn't been mentioned yet, and that I think narrows the fix: there is no Btw context in the keybindings registry at all. The documented context list is Global, Chat, Autocomplete, Confirmation, Help, Transcript, HistorySearch, Task, ThemePicker, Settings, Tabs, Attachments, Footer, MessageSelector, DiffDialog, DiffPanel, ModelPicker, Select, Plugin, Scroll — no btw/side-channel entry — and there is no btw:* action either.

So Esc typed inside btw scope isn't being "swallowed by the prompt" so much as it never had a handler of its own: it falls straight through to Confirmation → confirm:no (default keys escape, n). Same mechanism explains the sibling reports where Esc kills a focused background agent instead (chat:cancel, also escape).

Two consequences:

1. Users cannot work around this via ~/.claude/keybindings.json, because there is no context to rebind — the only lever is unbinding escape from Confirmation globally, which costs Esc-to-deny in every permission dialog and may just fall through to chat:cancel anyway.
2. The fix is probably small: register a btw context that consumes escape ahead of Confirmation/Chat, and expose it as a rebindable btw:exit action.

Related reports of the same root cause, all open: #74959, #78876, #81977, #69416 (auto-marked stale).

Reproduced on v2.1.233 (macOS, default permission mode).

Steps:

1. Start claude in an empty project.
2. Send a prompt that will need your input, e.g. Use the AskUserQuestion tool to ask me whether I prefer cats or dogs. (a Bash command that needs approval behaves the same).
3. Before the prompt appears, send /btw what is 3+3? answer in one word. The /btw overlay opens with the answer, and the question/permission prompt appears above it.
4. Press Esc once, intending to close the /btw overlay.

Observed: the Esc is consumed by the pending prompt — the transcript shows ⏺ User declined to answer questions (for the Bash case the command is rejected and never runs), and the /btw overlay is still open. A second Esc closes the overlay.

Expected: Esc closes the /btw overlay and leaves the pending question/permission prompt untouched.

Assessment: This is a genuine bug and a regression. Until roughly v2.1.141 (mid-May 2026), a permission or question prompt that arrived while the /btw overlay was open stayed hidden until you dismissed the overlay, so Esc only ever closed /btw. Since then the prompt is shown and takes keyboard focus underneath the still-open overlay, so the first Esc answers the prompt (as "no") instead of closing the overlay. The same root cause affects other overlays such as /usage (#86491). The fix is to keep pending permission prompts parked while a /btw-style overlay is open, so Esc goes to the overlay first.

🤖 Generated with Claude Code

I have found that <Return> instead of ESC exits the /btw without cancelling the prompt. It hasn't collided with a decision prompt for me yet, but I have not tested exhaustively.

Confirmed — reproduced on 2.1.233 (Linux terminal).

With the /btw panel open (showing "Esc to close") and a pending prompt in the main conversation, one press of Esc went to the pending prompt, not the panel:

• With a pending AskUserQuestion, Esc declined the question ("User declined to answer questions") while the /btw panel stayed open.
• With a pending Bash approval prompt, Esc rejected the tool call and interrupted the turn ("Interrupted · What should Claude do instead?"), again leaving the panel open.

A second Esc then closes the panel — exactly the behavior you describe. This is a real key-conflict bug: the panel's own "Esc to close" hint should win while it's focused. We're looking at making Esc close the /btw panel first (or giving the panel a distinct close key) so exiting the mode can't silently reject a pending tool call.

🤖 Generated with Claude Code

Cheap interim mitigation that needs no change to the propagation logic: the overlay already accepts Space and Enter to close, and neither key is treated as reject/cancel by the underlying prompt. So change the footer hint from "esc to close" to "space or enter to close". That steers users away from the colliding key for the common case even before the deeper fix lands.

The text change alone reduces the footgun.

Related open reports of the same root cause: #88013, #64568, #83026, #63092, #81977. Prior closed duplicates: #75201, #79045, #75680, #65153, #69416, #65781.

🤖 Generated with Claude Code

the overlay already accepts Space and Enter to close, and neither key is treated as reject/cancel by the underlying prompt. So change the footer hint from "esc to close" to "space or enter to close".

Wtf are "you" talking about?

The /btw panel treats Space as an input character for the prompt field - you know, the purpose of the prompt field - and Enter as the submit key for that prompt.

So no, neither key "closes the overlay" in any meaningful sense while the prompt is focused. They perform the exact actions they’re supposed to perform.

Just make the panel capture the Escape key, and not the underlying stuff.

🧠 Generated with my fucking brain