Auto mode: AskUserQuestion timeout (60s) should be configurable, or the session should wait instead of auto-selecting

Summary

In Auto Mode, AskUserQuestion currently times out after ~60 seconds if the user hasn't responded, and the session then proceeds using the model's own judgment rather than waiting for the actual answer. This is disruptive when multi-tasking with Claude Code running in the background: a question gets raised, the user doesn't see/answer it within 60 seconds, and Claude Code picks an option and continues autonomously — sometimes taking an action the user did not intend or would have answered differently.

As reported: "Auto mode AskQuestion timeout of 60 seconds needs to be configurable. Or it needs to stop the session and wait if no response is received. When multi-tasking with Claude Code, having it ask an unexpected question, and then continue with a random option chosen, is unacceptable."

Problem

• 60 seconds is too short for realistic multi-tasking (checking another window, in a meeting, away from the desk, etc.).
• There is currently no setting to configure or extend this timeout.
• Silently proceeding with an inferred "best judgment" choice after timing out can lead to unintended side effects being applied before the user has had a real chance to read and answer the question — especially for questions gating something with real consequences (config/permission changes, destructive operations, etc.).

Suggested fix (either would help; both would be ideal)

1. Make the timeout configurable — e.g. a settings.json field (global and/or project-level) controlling how long AskUserQuestion waits before falling back to a default, so users who need longer multi-tasking windows can extend it (or disable the fallback entirely).
2. On timeout, pause and wait rather than auto-selecting — at minimum for questions whose options have real side effects, hold the turn instead of continuing on an inferred default. A model "proceeding on best judgment" is a reasonable fallback for genuinely low-stakes ambiguity, but should not be the automatic behavior for every timed-out question regardless of stakes.

Example from a real session

During a multi-step session, Claude Code asked a clarifying question about whether to modify a hook in the user's global Claude Code config. The user was away from the keyboard for longer than 60 seconds, so the session proceeded on its own judgment rather than waiting. This required additional back-and-forth to correct once the user returned — which would have been unnecessary if the session had simply held the question open until answered.

---
Filed via user request through a Claude Code session.