[BUG] Autocontinue after 60s not possible to be disabled
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?
Body:
Description
AskUserQuestion silently auto-proceeds if the user doesn't respond within 60 seconds, and there is no setting, flag, or environment variable anywhere that disables this behavior. For workflows where a question's answer
materially changes what gets built (scope decisions, design choices, anything explicitly gated behind user input), this causes the agent to act on an assumed/guessed answer instead of the user's actual one — with no way to
opt out.
Actual Behavior
The 60-second timeout and auto-proceed fallback are hardcoded with no override. This was confirmed against the full settings reference doc and the permission-modes doc — neither exposes a relevant option.
Impact
Silent wrong-direction work: the agent can commit to an approach, reframe a problem, or scope a change based on a guessed answer instead of the user's actual intent, and the user may not notice until well after the fact.
Proposed Fix
A settings.json (or CLI flag) option, e.g.:
{
"askUserQuestion": {
"onTimeout": "wait" // default: "proceed" (current behavior) | "wait" (block indefinitely)
}
}
When set to "wait", the tool should keep blocking until the user actually answers — no assumed default, no fallback result returned to the model.
Related Issues
- #30740 — requested a configurable timeout duration; closed as "not planned." This report is narrower: it's about the inability to disable the auto-proceed fallback entirely, not adjust its length.
- #22597, #70294 — request more auto-continue for unattended/remote use cases; this report asks for the opposite behavior, opt-in per user/session.
Environment
- Claude Code CLI
- OS: Windows 11
What Should Happen?
There should be a way to configure AskUserQuestion to block indefinitely until the user responds, with no timeout-triggered fallback and no "proceed on your best judgment" instruction ever reaching the model.
Error Messages/Logs
Steps to Reproduce
- Trigger a flow that calls AskUserQuestion with one or more questions.
- Don't respond within 60 seconds (e.g., step away from keyboard).
- Observe that the tool returns "No response after 60s — the user may be away from keyboard. Proceed using your best judgment based on the context so far; you can re-ask this question later if it's still relevant."
- The agent then proceeds based on assumptions, without the user's real answer.
- Search settings.json, settings.local.json, env vars, CLI flags, and permission modes (default, acceptEdits, plan, auto, dontAsk, bypassPermissions) for any way to prevent this — none exists.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.198 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Confirming this from a workflow-automation angle, and +1 to the
"onTimeout": "wait"opt-out specifically.I build a task-management framework on top of Claude Code where several
AskUserQuestionprompts are load-bearing, non-skippable gates — plan approval, "commit these changes?", merge approval. Their whole purpose is that the agent must not proceed until the human actually answers. The hardcoded 60s auto-proceed silently defeats exactly that guarantee: step away for a minute and the tool hands the model "proceed using your best judgment," turning an explicit gate into a guess.Per #73408 the internal knob appears to already exist as
afkTimeoutMs— it's just undocumented with no user-facing override, which matches what I found: nothing in the settings reference, permission-modes doc, env vars, or CLI flags exposes it.The narrow ask here is the right one: not "make the duration longer," but "let me disable the auto-proceed fallback entirely," so no assumed answer and no 'best judgment' instruction ever reaches the model. Ideally the opt-out is also settable per-question (a
blocking: trueflag on the tool call) so a workflow author can mark specific safety gates as never-auto-proceed even if the global default stays as-is for unattended use.I also ran into this undesired behavior this morning - I run a workflow where AskUserQuestion prompts are specific "Human in the Loop" gates and I do NOT want them to auto-accept.
If they NEED to timeout then okay, that's fine, but the model should pause at that point and wait for me to come back and address the feedback. (Either leaving me a summary of the questions it was asking so I can answer them to continue the prompt, or the ability to ask the questions again once I'm back)
This is a disaster! It's pretty disturbing change, especially in "auto-mode" that let's the agent decide the next steps on its own. Unacceptable.
+1, hit this too. Trying to prevent it via a hook, but there's no way to intercept the timeout/auto-proceed behavior itself — hooks can only react to the
Elicitationevent, not extend or disable the countdown. This needs to be a first-class setting, since blocking at the hook layer risks silently swallowing the question entirely (worse than the current auto-accept).The proposed
askUserQuestion.onTimeout: "wait"option in the description above would fully solve this.+1. The
askUserQuestion.onTimeout: "wait"of the description solves the issue, and it should be a default value!This new behavior literally ruins the agentic coding paradigm as we know it.