[BUG] `/btw` overlay blocks permission prompt dialog visibility

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When /btw is used to inject a side-message during an active turn, the resulting overlay occludes any permission-request dialog Claude raises during that same turn (e.g., "Allow Edit to file X?"). The dialog is not dismissed — it is simply invisible, leaving the turn blocked with no visible way to approve or deny.

Other in-turn UI elements (progress bullets, status lines, tool-use indicators) continue to render and update normally alongside the /btw overlay.

What Should Happen?

Either:

• The permission dialog renders on top of the /btw overlay so the user can approve/deny, or
• The /btw overlay auto-dismisses (or visually de-prioritizes) when a blocking permission prompt is raised.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session in a project where Claude will need permission to edit files.
2. Give Claude a task that requires a permission-gated tool call (e.g., "Edit file X to add Y").
3. While Claude is mid-turn and about to call a gated tool, submit /btw <any message> to inject a side-note.
4. Claude reaches the permission-gated tool call and the harness fires a permission prompt.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.116

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related issues:

• #44876 — /btw side-question context where the user cannot respond to Claude's clarifying questions. Confirms /btw has prior input/UI interaction problems.
• #47969 — general permission-dialog visibility problems in other contexts.