[FEATURE] Surface interactive CLI prompts through Claude Code's user-facing UI

[FEATURE] Surface interactive CLI prompts through Claude Code's user-facing UI

Problem

When Claude Code runs a CLI tool via the Bash tool that requires interactive input (selection menus, confirmation prompts), the agent has two options: guess the answer or pipe input. Neither is ideal:

• Guessing bypasses the CLI's safety mechanisms (e.g., confirmation before a destructive action)
• Piping (e.g., echo "y" | my-cli send ...) works but the user never sees the prompt or makes the decision

There is no way for a CLI tool's interactive prompt to reach the user through Claude Code's UI. The agent sits between the tool and the user, silently deciding on their behalf.

Use case

I maintain a Telegram CLI tool (tg). I'm adding a tg send command that posts messages to chats. Since sending is irreversible and externally visible, the command shows a preview and asks for confirmation:

┌─ Preview ────────────────────────┐
│ To:      Finance Team            │
│ Message: hello everyone          │
└──────────────────────────────────┘
Send this message? [y/N]:

When a user runs this directly in their terminal, the flow is clear: they see the preview, type y or n. But when Claude Code runs tg send "Finance Team" "hello", the confirmation prompt goes into a void. Claude Code either:

1. Answers y on the user's behalf (unsafe, defeats the purpose of the prompt)
2. Gets EOF on stdin and the command aborts (safe but useless)
3. Decides not to run the command at all (overly cautious)

None of these outcomes let the user make the decision.

Proposed behavior

When a Bash command outputs an interactive prompt (waiting for stdin), Claude Code should be able to surface it to the user through its existing UI, similar to how AskUserQuestion works:

1. Bash command outputs a prompt and blocks on stdin
2. Claude Code detects the blocked state and the prompt text
3. Claude Code presents the prompt to the user in its UI
4. User responds
5. Claude Code pipes the response back to the command's stdin

This would allow CLI tools to maintain their safety mechanisms while being fully usable through Claude Code.

Why this matters beyond my use case

Many CLI tools use interactive prompts for safety-critical operations: package managers asking before install, git prompts before force-push, database tools confirming before destructive queries, deployment tools confirming target environments. Today, Claude Code either bypasses these safeguards or avoids running the commands entirely. A passthrough mechanism would make Claude Code compatible with the broader CLI ecosystem's safety patterns.

Alternatives considered

• --yes / --no-confirm flags: shifts safety responsibility to the agent, which can easily set these flags
• Config-based skip: better (harder to set accidentally), but still bypasses the prompt entirely
• Two-step CLI design (preview command + separate execute command): works but forces every CLI to redesign around agent limitations
• Agent manually recreates the prompt via AskUserQuestion: fragile, requires the agent to parse CLI output and reconstruct the prompt

Related issues

• #9881 (Interactive Shell Support via PTY)
• #16306 (stdin hang in sandbox mode)
• #15553 (Programmatic Input Submission)