[BUG] AskUserQuestion is blocking text
Resolved 💬 20 comments Opened Feb 7, 2026 by Seraphli Closed May 14, 2026
💡 Likely answer: A maintainer (claude[bot], contributor)
responded on this thread — see the highlighted reply below.
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?
In the CLI, every time Claude outputs a bunch of text and then immediately calls the AskUserQuestion tool, AskUserQuestion ends up covering part of the original output. You can only see the text afterward if you cancel it.
What Should Happen?
AskUserQuestion will not cause obstruction
Error Messages/Logs
Steps to Reproduce
You can easily reproduce this issue. First, have Claude Code output a long passage of text, then have Claude Code call the AskUserQuestion tool. Finally, have it do both together in one go.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.34
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
_No response_
20 Comments
I am also seeing this, if its relevant it is with iTerm2 and ZSH. I also see this on linux/foot/zsh
I also have this issue.
Also have this, using WezTerm
I also see this in WezTerm, running claude locally in zsh and over ssh in bash.
Experiencing this issue in zsh on Mac. Happens pretty much every time AskUserQuestion tool is shown
Also have this using warp mac, block 1 line every time.
Happen over here as well. Ghostty. Mac.
Experiencing this on WSL2 (Windows Terminal). Same behavior — last 2-3 lines of output before AskUserQuestion are overwritten and unrecoverable, even via scrollback.
Environment:
The custom statusline may exacerbate the line count slightly, but the core issue reproduces regardless. This is a significant UX problem when AskUserQuestion is used frequently. The context leading into the question (often the reasoning for why Claude is asking) gets lost, forcing you to guess what was being communicated.
Would love to see this prioritized, as it's a daily friction point.
As an embarrassing workaround I have this in my CLAUDE.md, which mostly works:
I'm using the claude desktop app and the popup literally blocks the response, i can't read it to answer the question! Pretty major UX fail.
Adding this section as a temporary workaround inside my
CLAUDE.mdfixed the issue:A simpler workaround than editing your CLAUDE.md is pressing
ctrl+oat the question prompt and it will hide the question and multiple choice section, revealing the hidden text.<img width="1459" height="808" alt="Image" src="https://github.com/user-attachments/assets/302a464a-7255-46b1-98bc-98237aca5a64" />
Press
ctrl+o<img width="1459" height="808" alt="Image" src="https://github.com/user-attachments/assets/f65c416d-f944-4738-8686-3d30765dc308" />
This is a major annoyance. If I flash a page in front of you so quick that you can't read any of it, and then ask you if you agree, how would you feel?
Make AskUserQuestion collapsible and fix the dimming, so I can see what I am responding to.
Same issue for me.
macOS, iTerm2 and ZSH
So glad this is reported and others are seeing it. This is a frustrating bug. I was typically exiting the answers so I could make sure I had read everything, and then asked Claude to show me the questions again. So counter-intuitive.
Recently I have added the following workaround to my
~/.claude/CLAUDE.mdand it is helping:This is happening for me, as well. Major issue.
Ctrl+O is the best workaround for the time being
I can reproduce this issue on macOS (Claude Code 2.1.138). The workaround doesn't address the root cause — it just shifts the problem elsewhere. The real issue is that users are answering the question without seeing the full context that preceded it, which can lead to incorrect answers and confusing follow-ups.
Please consider fixing this properly rather than relying on workarounds.
This is a duplicate of #58207, which was fixed as of version 2.1.141.
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.