Interactive prompts (AskUserQuestion / option-pick) hang the session with no timeout and aren't surfaced to remote channels (Telegram), stranding remote users

Status Open

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jun 23, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

What happens

When Claude Code is waiting on an interactive prompt — an AskUserQuestion / "pick one of these options" prompt, or any prompt that blocks on the user's input — the session becomes completely unresponsive and blocks indefinitely. It never times out and never falls through to a default. The session just sits there silently waiting forever.

This is painful enough locally, but it becomes a hard dead-end when driving Claude Code remotely (e.g. via a channel plugin such as Telegram/Slack/Discord):

The interactive question and its options are not surfaced to the remote channel at all. The remote user can't even see the question — let alone answer it.
From the remote user's side, the session just goes silent. There's no indication that Claude is blocked, no question to respond to, and no way to unblock it short of physically walking to the terminal.
Because the prompt never times out, the session stays wedged indefinitely with no recovery path.

For comparison, Codex handles the analogous situation more gracefully — interactive waits time out / fall through rather than blocking the agent forever.

Why it matters

A core use case for the channel plugins is operating Claude Code away from the terminal. An interactive prompt that (a) is invisible to the channel and (b) never times out completely strands a remote user: the session is hung, silent, and unrecoverable from the channel side. This is the single biggest reliability cliff when running Claude Code remotely.

Repro

Drive a Claude Code session through a remote channel plugin (e.g. the Telegram channel plugin).
From the remote channel, trigger work that causes Claude to raise an interactive question (AskUserQuestion / option-pick / any blocking prompt).
Observe:

The question + its options are not shown in the remote channel.
The remote user gets no indication the session is blocked.
The session hangs with no timeout and cannot be unblocked from the channel.

Requests

Time out / fall through interactive prompts instead of blocking the session forever. When a prompt has been waiting beyond a (configurable) timeout with no response, fall back to a sensible default — proceed, cancel, or pick the default option — rather than hanging indefinitely, the way Codex does. At minimum, give the prompt a bounded lifetime so a session can't get permanently wedged.

Surface interactive questions to the active remote channel. When a session is being driven through a channel (Telegram/Slack/Discord/etc.), the interactive question text and its options should be relayed to that channel so the remote user can read and answer it (and their reply routed back as the answer). At the very least, the session should signal to the channel that it's blocked waiting on input, instead of going silently dark.

Related prior issues

Both halves of this have been raised separately before but are currently closed/stale, and neither captures the combined "no timeout and invisible to the channel = remote user permanently stranded" failure mode:

#37113 — Allow AskUserQuestion to be dismissed programmatically or with a timeout (closed/stale)
#36722 — Clarifying questions / interactive prompts don't route through channel; Telegram/Discord users see silence (closed/stale)
#37573 — AskUserQuestion tool not surfaced to Telegram plugin users (closed as duplicate)

Filing this as a consolidated bug/feature because the combination — hung-forever + not-surfaced-to-channel — is what actually strands remote users in practice, and the prior single-angle issues went stale without a fix.

🤖 Generated with Claude Code

View original on GitHub ↗

3 Comments

rlmumford · 1 month ago

Following up: as of v2.1.198 the behavior in this report has flipped to the opposite failure mode, and it shipped silently (no changelog/docs entry I can find).

Previously AskUserQuestion blocked indefinitely with no timeout (this issue). It now auto-returns after a fixed 60 seconds with this verbatim result:

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.

(first observed on v2.1.198; see also #73125, which quotes the same string and flags it as a regression from ~2.1.196.)

This addresses the "hangs forever" half of this report but overcorrects. AskUserQuestion is an explicit approval checkpoint — people (and PreToolUse hooks / CLAUDE.md rules) rely on it to gate consequential actions on a real human decision. Auto-proceeding "using your best judgment" turns a deliberate stop into silently-continue the moment the user steps away for 60s: the model can commit, push, or take the exact action it was asking permission for, purely because the human took longer than a minute to read the options. The tool schema exposes only questions/answers/metadata — there's no parameter to change this and no way to opt out.

Three requests:

Configurable timeout duration — a setting (project/user/managed settings.json, or a CLI/tool option) to raise the 60s window or disable the timer.
Opt-out of the auto-proceed fall-through — a way to restore blocking (or the remote-surfacing this issue originally asked for) so a timeout does not return "proceed with best judgment." For agentic / unattended use, blocking indefinitely is often the safer default. At minimum, make the fall-through result distinct enough that a PreToolUse hook or CLAUDE.md rule can reliably detect "this was a timeout, not an answer" and refuse to act.
An audit trail for timeout-driven actions — when the model does auto-proceed, there is currently no way to find out what it did in the user's absence, and asking the session afterward ("what did you decide while I was away?") often gets a refusal, because the model doesn't treat a timeout-proceed as a decision it made and won't account for it. Actions taken past a timeout should be recorded and surfaced back to the user on their return (or at the next input prompt), so a stop that silently continued is at least auditable.

Either way, this changed behavior in a safety-relevant tool should be documented and land in the changelog — right now it's a silent regression.

Blue-Cardigan · 1 month ago

Workaround for the AskUserQuestion ~60s auto-advance (found by inspecting the compiled binary, so undocumented and may change): it's an AFK auto-advance timer gated by the env var CLAUDE_AFK_TIMEOUT_MS (integer ms of user idle before auto-advance, default 60000; any keypress resets it). CLAUDE_AFK_COUNTDOWN_MS (default 20000) controls when the "auto-continue in Xs · any key to stay" footer appears.

To effectively disable, add to ~/.claude/settings.json:

"env": { "CLAUDE_AFK_TIMEOUT_MS": "86400000" }

Do not set it to 0 — the code reads env ?? 60000 and compares idle-time >= the value, so 0 fires immediately instead of disabling. Takes effect on next session. Verified working on 2.1.198 (2026-07-02): waited 90s+ idle on an AskUserQuestion prompt with no countdown and no auto-advance.

Separately, the SDK/remote "Claude needs your input" dialog timeout is gated by CLAUDE_CODE_USER_DIALOG_TIMEOUT_MS (default 300000), and that one does disable at 0 (if (timeout > 0) guard).

bcherny collaborator · 14 days ago

Thanks for the report. Two things exist today that help, though neither fully covers AskUserQuestion:

Channel servers can opt into permission relay so tool-approval prompts are forwarded to the chat app and answered remotely: https://code.claude.com/docs/en/channels-reference#relay-permission-prompts
Running the session with -p (non-interactive) disables tools that need terminal input (multiple-choice questions, plan approval) so the session never stalls: https://code.claude.com/docs/en/channels

Relaying interactive questions to a channel, or a timeout/default for them, isn't shipped, so leaving this open as a feature request.