[BUG] Autocontinue after 60s not possible to be disabled

Status Fixed / completed
Reported on v2.1.198
Maintainer reply None cached
Activity 6 comments · opened Jul 2, 2026 · closed Aug 17, 2026

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

  1. Trigger a flow that calls AskUserQuestion with one or more questions.
  2. Don't respond within 60 seconds (e.g., step away from keyboard).
  3. 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."
  4. The agent then proceeds based on assumptions, without the user's real answer.
  5. 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_

View original on GitHub ↗

5 Comments

beyondeye · 1 month ago

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 AskUserQuestion prompts 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: true flag 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.

chrisheninger · 1 month ago

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)

yuri-tceretian · 1 month ago

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.

flo-ri-an · 1 month ago

+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 Elicitation event, 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.

le-clucien · 1 month ago

+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.

Showing cached comments. Read the full discussion on GitHub ↗