[FEATURE]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

AskUserQuestion has a hardcoded 60s timeout. When it fires, the tool
returns an empty/incomplete response, and the agent can't tell "user
chose nothing" from "user didn't answer in time" — so it often proceeds
on default assumptions.

Two real pain points:

1. Broken flow: step away for a minute and the picker resolves itself

with no input, then continues as if you'd decided. Load-bearing
choices get made without you.

1. Unattended/remote runs: in headless or channel-driven sessions the

question may not surface at all, so 60s is effectively the only
"answer" (see #70294).

This reopens #30740, which was auto-closed as stale without resolution.

Proposed Solution

• Configurable timeout via ~/.claude/settings.json or project

.claude/settings.json (e.g. askUserQuestionTimeoutMs)

• Option to disable the timeout entirely (wait indefinitely)
• On timeout, return a clearly-typed "no response" result the agent can

branch on, instead of an empty selection it may treat as a valid choice

Alternative Solutions

Steering via CLAUDE.md to avoid the option-picker and ask in plain prose
instead — works, but it's a workaround, not a fix, and doesn't help
unattended sessions. Also tried instructing the agent to re-confirm on
empty responses, but it can't reliably detect the timeout case.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

1. I'm running a Claude Code session in plan mode and it hits me with an

AskUserQuestion option-picker for two load-bearing design choices.

1. I glance at Slack for ~90s to answer a coworker.
2. The picker times out at 60s, returns an empty selection, and Claude

continues — picking defaults for both choices without me.

1. I come back to a plan built on assumptions I never agreed to, and have

to unwind it. A configurable/disableable timeout would've let it wait.

Additional Context

The empty-response behavior is the core issue — the agent can't tell a
timeout apart from a deliberate "no selection," so it proceeds as if
answered. Higher-severity version of #70294 (remote sessions never even
see the question). Priority: High — breaks flow on any unattended or
briefly-unattended session.