AskUserQuestion auto-selects default answer after ~60s idle — no way to configure or disable (v2.1.198)
Status Open
Reported on v2.1.198
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 8 comments · opened Jul 2, 2026
What happened
On Claude Code v2.1.198, when Claude uses the AskUserQuestion tool to ask a multiple-choice question, the prompt auto-selects the default/first option after ~60 seconds of no user input, then continues the turn as if I had answered.
This means a choice I never made gets silently committed. There is no documented way to lengthen this idle window or disable the auto-answer so the question waits until I actually respond.
Expected behavior
A supported setting to control this — e.g. a settings.json key or env var to:
- set the idle window (e.g.
askUserQuestion.idleTimeoutMs), and/or - disable the auto-answer entirely so the prompt blocks until answered.
Environment
- Claude Code: 2.1.198
- OS: Windows 11 Enterprise (26200)
- Terminal: interactive CLI session
Notes / prior art
- The behavior is undocumented — I checked the changelog for 2.1.185–2.1.198 and found no entry describing an AskUserQuestion idle timeout or auto-select.
- The only public 60s idle mechanism I could find is the
idle_promptNotification hook, whose timeout is hardcoded (#13922). ANotificationhook onidle_promptcan alert the user but cannot extend or suppress the timer (Notification is display-only). - Related: #30740 (request for configurable AskUserQuestion timeout, closed as not planned), #70294 (interactive prompts hang / not surfaced to remote channels).
Request
Please either document the current 60s auto-default behavior, or add a config knob to adjust/disable it. Reopening #30740 may be the right home for this since the behavior now ships live rather than being hypothetical.
8 Comments
this should have been an afk mode can be toggled on and off, it completely broke my workflow
@bcherny this is critical, it cause unwanted results.
One workaround that usually helps: adding an instruction in
CLAUDE.mdtelling the agent to wait for input rather than proceeding. It mostly works, but it adds latency to every prompt, so it is not a real substitute for the prompt simply waiting.More broadly this feels like a UX gap rather than an edge case. Orchestrating several agents at once is a normal way to work now, and it means chats are routinely left unattended for a while as attention moves between them. Auto-selecting a default after 60s assumes someone is watching the whole time, which often is not the case. A setting to disable the auto-answer so the prompt just waits would fit how people actually use the tool.
Agreed, this is absolutely a pain to deal with right now when. working in multiple sessions at a time. There really needs to be a way to disable the auto-answer functionality.
I've been using the same workaround as @danedwardsdeveloper mentioned, but it does slow things down quite a bit. The risk of having a bad auto-selected option is pretty much guaranteed, and if you're not careful, it will slip through into the final plan.
@bcherny can I bribe you with coffee to vibe up a fix 😄
I have this feeling now that even when I am looking at interactive prompts that the clock is ticking and the Countdown music is playing in the background. Micro stress. Please can you make it opt IN too
Thankfully, this has been fixed in release v2.1.200
I would say the unwanted feature has been silently removed rather than it has been fixed. But there's always stuff to learn with UX and they probably thought it was a good idea at the time hehehe
Thanks for pointing out this changelog. The situation on the main issue where this was being discussed:
https://github.com/anthropics/claude-code/issues/73125
is confusing
<img width="952" height="231" alt="Image" src="https://github.com/user-attachments/assets/b7ad7e72-6a3b-439c-bda4-18aa3d3d947a" />
and the issue has been closed without clarification.