[FEATURE] : Opt-in Host-Shell Execution Mode with Full stdin Passthrough

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

Problem

When Claude Code executes commands that require mid-execution user input — such as sudo password prompts, SSH passphrases, package manager confirmations (y/n), or any interactive CLI tool — the process either hangs indefinitely or times out silently. There is currently no mechanism for Claude Code to detect that a running process is waiting for user input, surface that prompt, and pipe the response back to the process.

This is not an edge case. It is a consistent blocker for any workflow involving:

• System administration (sudo apt install, sudo systemctl, etc.)
• Deployment scripts that require privilege escalation mid-execution
• SSH connections with passphrase-protected keys
• Package managers with interactive confirmation steps (pip, npm, brew)
• Any CLI tool that uses getpass() or reads directly from /dev/stdin
• git operations requiring credential prompts (git push to protected remotes, etc.)

---

Root Cause

The Bash tool runs with stdin disconnected or set to non-interactive mode, meaning any process that attempts to read from stdin blocks forever with no path to resolution. The absence of a PTY also means that tools like sudo behave differently — they detect the non-TTY environment and either refuse to run or produce no output at all.

---

Expected Behavior

User asks Claude Code to run a deployment script requiring sudo
       ↓
Claude Code executes the script in the real host shell (opt-in mode)
       ↓
Script reaches: [sudo] password for user:
       ↓
Claude Code detects process is waiting for stdin
       ↓
Claude Code surfaces the prompt to the user (masked input)
       ↓
User types password → piped back to process
       ↓
Script resumes and completes normally

---

Additional Notes

• This is intentionally proposed as an opt-in flag, not a default behavior change. The safety implications of host-level execution are real and should remain the user's explicit choice.
• The feature would unlock a whole class of professional workflows — DevOps, system administration, infrastructure automation, and deployment pipelines — that are currently out of reach for Claude Code.
• A clear warning on first use of the flag (similar to how other CLIs handle dangerous modes) would be appropriate to ensure users understand what they are enabling.
• This is distinct from simply requesting PTY support for TUI applications — the specific need here is stdin passthrough during privileged or interactive command execution, which requires both PTY and a direct connection to the user's host shell.

Proposed Solution

Proposed Solution

An opt-in --host-shell flag (or equivalent config entry in settings.json) that:

1. Spawns commands directly inside the user's real terminal session with their actual system permissions — no isolation layer between Claude Code and the host OS
2. Uses a PTY (pseudo-terminal) to ensure the running process believes it is inside a real terminal — critical for tools like sudo that behave differently in non-TTY environments
3. Detects when a running process is waiting for stdin input
4. Surfaces the prompt to the user and accepts their input (masked for passwords, raw for confirmations)
5. Pipes the response back to the running process and resumes execution seamlessly

This must be strictly opt-in — users who enable it explicitly accept the responsibility that comes with full host-level execution. Users who do not set the flag are completely unaffected and retain current behavior.

Alternative Solutions

Current Workaround

None that preserves agent context. The only option today is to abandon the Claude Code session, run the privileged command manually in a separate terminal, then return — which breaks agentic flow entirely and defeats the purpose of continuous task execution.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I am working on a deployment automation workflow where Claude Code is tasked with running a multi-step shell script that includes system-level operations. Midway through execution, the script reaches a sudo command and requires a password. Claude Code's Bash tool has no mechanism to detect the prompt or accept input — the process hangs silently until it times out, losing all execution context.
The same issue occurs when:

Running ssh to a remote server with a passphrase-protected key
Executing npm login or pip install with confirmation prompts
Any deployment script that calls sudo systemctl restart or similar privileged operations
git push to remotes requiring credential prompts

In every case, the only resolution is to abandon the Claude Code session entirely, run the command manually in a separate terminal, and restart — breaking the agentic workflow completely.

Additional Context

Technical considerations:

Implementation would likely require a pseudo-terminal (PTY) layer to ensure processes like sudo believe they are running inside a real TTY — without this, many privileged tools behave differently or refuse to run entirely
stdin passthrough requires detecting when a running process is blocked waiting for input, then surfacing that state to the user
Password input should be masked; raw confirmation prompts (y/n) can be passed through directly
This should be strictly opt-in via a flag or settings.json entry — default behavior must remain unchanged, and users who enable it explicitly accept the responsibility of full host-level execution
A clear warning on first use of the opt-in flag would be appropriate

Related open issues:

#9881 — PTY / Interactive Shell support
#26353 — Interactive TTY mode for bash
#27294 — Surface interactive CLI prompts

Prior art:
Similar implementations exist in other agentic CLI tools using node-pty as the underlying approach, confirming this is technically feasible and has been successfully shipped in production environments.Share