[BUG] Expanded view silently suppresses permission request dialog
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 toggled into expanded view if the agent request permission for an action it will "fall through" and the agent runtime will hang until you kill the request and manually request the agent to retry.
What Should Happen?
When an agent requests permission it should stack on top of the text input view so toggling out of the expanded view surfaces the permission request. Or at the very least pending permission view needs to be accessible by the user.
Error Messages/Logs
Steps to Reproduce
- Ask Claude a question that for a command that doesn't require permission followed by a command that does. Such as
Check the current directory for hello.txt and if it does not exist create the file with the content "hello world". - When it executes the action it has permission for, use
ctrl+oto enter the expanded view, until you see the permission prompt summary in the log. - The write permission dialog will not be present once you toggle off the expanded view.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.153 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
I'm using ghostty as my terminal emulator and tmux for terminal management on macOS, but using terminal.App also surfaced this issue.
Screenshot of infinite hang:
<img width="872" height="526" alt="Image" src="https://github.com/user-attachments/assets/8956bfd8-4839-4b49-aff1-198c5331acae" />
3 Comments
Reproduced the hang — entering the expanded view (ctrl+o) while a permission prompt is pending does leave the request stranded with no visible dialog. A couple of notes that may help others who hit this:
Recovering from a stranded request: press Esc to cancel the pending tool call, toggle out of the expanded view (ctrl+o), then ask it to retry. The agent unblocks once the orphaned permission request is cancelled.
Avoiding the hang for commands you trust: if the action that triggers the prompt is one you've already decided is safe, pre-allowing it in settings means no dialog is raised in the first place, so there's nothing to get stranded. For your repro's
Writeexample:You can scope it tighter than the whole tool — e.g.
Bash(git status:*)for a specific command, or a path-scopedEditrule — so you only auto-approve what you actually trust and still get the dialog for everything else. Caveat: this is a deliberate trade-off (the command then runs without a prompt everywhere, not just in expanded view), so only allowlist operations you're comfortable running unattended.That sidesteps the symptom but isn't a fix — the dialog genuinely shouldn't be swallowed by the expanded view. Agree with your suggestion that a pending permission request should either stack above the input or remain reachable after toggling back. Confirming it's a regression here too (2.1.153).
This is fixed as of
2.1.178 (Claude Code)on both/tui fullscreenand/tui default.If someone wants to hunt down the exact version that introduces this fix feel free. But I am closing the issue.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.