AskUserQuestion 60s auto-proceed is too short for considered decisions — make the timeout configurable (ref #30740, #70294)

What happens

When AskUserQuestion is shown, if the user doesn't answer within ~60 seconds the tool auto-returns No response after 60s — the user may be away from keyboard and the model proceeds without an answer, often on a guessed default.

Why this is a problem

The questions worth surfacing via AskUserQuestion are, by definition, the ones that need thought — architecture decisions, scope trade-offs, irreversible choices. 60 seconds is not enough time to reason about exactly those. In practice it forces the user to stare at the terminal continuously so they don't miss a decision window, and even then a minute is often too short. The failure mode is silent: the model proceeds on a default, and a real decision gets made by timeout rather than by the human.

Why a fixed 60s is the wrong design (not just the wrong value)

These two issues pull in opposite directions:

• #30740 (closed not-planned, now locked) asked for a configurable / disable-able timeout.
• #70294 (open) reports the opposite pain: on remote channels (Telegram) prompts hang with no timeout, stranding remote users.

A single hard-coded value cannot serve both a remote/headless session (wants a timeout so it doesn't hang) and an interactive TTY session (wants a long or infinite timeout so the human can deliberate). The resolution both issues point to is configurability, not a fixed number.

Request

Expose the AskUserQuestion timeout as a setting — e.g. a settings.json field and/or an env var — with support for "disable / wait indefinitely" for interactive TTY sessions, while letting remote/headless setups keep a finite timeout. (#30740 was closed for inactivity and is locked; filing fresh per the bot's instruction and referencing it + #70294.)

Environment

Claude Code 2.1.198, macOS (Darwin 25.5.0). Interactive terminal session.

Note

A tool-specific workaround exists for the GSD workflow toolkit (a text_mode that renders questions as plain untimed text), but that only covers one consumer of the prompt — the underlying tool timeout still affects every other use.