Interactive prompts (AskUserQuestion / option-pick) hang the session with no timeout and aren't surfaced to remote channels (Telegram), stranding remote users
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
AskUserQuestionto 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 —
AskUserQuestiontool 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
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗