Repository navigation
[FEATURE]: Opt-in Host-Shell Execution Mode with Full stdin Passthrough #18659
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
When OpenCode 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 OpenCode 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
Root Cause
The current shell execution environment runs with stdin disconnected or non-interactive, meaning any process that attempts to read from stdin blocks forever with no path to resolution. Even with PTY support partially present in the codebase (noted in v1.2.21 fix), there is no user-facing mechanism to feed input to a running process.
Proposed Solution
An opt-in --host-shell flag (or equivalent config option) that:
- Spawns commands directly inside the user's real terminal session with their actual system permissions — no isolation layer between OpenCode and the host OS
- Uses a PTY to ensure the running process believes it is inside a real terminal (critical for tools like
sudothat behave differently in non-TTY environments) - Detects when a running process is waiting for stdin input
- Surfaces the prompt to the user and accepts their input (masked for passwords)
- Pipes the response back to the running process and resumes execution seamlessly
This should be opt-in, not the default — users who enable it explicitly accept the responsibility that comes with full host-level execution.
Expected Behavior
User asks OpenCode to run a deployment script requiring sudo
↓
OpenCode executes the script in the real host shell
↓
Script reaches: [sudo] password for user:
↓
OpenCode detects process is waiting for stdin
↓
OpenCode surfaces the prompt to the user (masked input)
↓
User types password → piped back to process
↓
Script resumes and completes normally
Current Workaround
None that preserves agent context. The only option today is to abandon the OpenCode session, run the command manually in a separate terminal, then return — which defeats the purpose of an agentic workflow entirely.
Additional Notes
- The v1.2.21 PTY session handle leak fix suggests the PTY infrastructure is at least partially present. The delta between what exists and what this feature needs may be smaller than it appears.
- This is intentionally proposed as an opt-in flag to avoid any safety concerns about default behavior. Users who don't set the flag are completely unaffected.
- This would make OpenCode viable for a whole class of professional workflows — DevOps, system administration, deployment automation — that are currently out of reach.
Activity
github-actions commentedon Mar 22, 2026
This issue might be a duplicate of existing issues. Please check:
sudo, password prompts, and interactive commands blocked by disconnected stdin. The root cause analysis and proposed solution closely overlap with this issue.Please review #9808 and consider whether your request adds anything new that isn't already covered there. If it does, please clarify the distinction so maintainers can evaluate both.
ArabianCowboy commentedon Mar 22, 2026
Thank you for flagging #9808 — I reviewed it and there is significant overlap. However, I want to clarify one distinction that I believe is worth tracking separately:
#9808 focuses on PTY and stdin passthrough — the mechanics of accepting interactive input mid-execution.
This issue goes one level deeper — it proposes an opt-in host-shell execution mode where commands are spawned directly in the user's real terminal session with their actual system permissions, with no isolation layer between the tool and the host OS. PTY + stdin passthrough alone is not sufficient if the execution environment itself imposes privilege restrictions (e.g., no_new_privileges, broken sudo ownership) that survive even after PTY is added.
In other words: PTY fixes how input is passed. Host-shell mode fixes where the command runs. Both are needed for sudo to work end-to-end reliably.
Happy to have this merged into #9808 as a comment if maintainers prefer to consolidate — but wanted to clarify the distinction first.
neolectron commentedon Apr 8, 2026
Is this how cursor does it ? A friend of mine had cursor just open a terminal on his linux pc and he could just write and interact with, then close it with Ctrl+C and the agent did pick it back up at the end of the session. This looks really useful, rather than having the shell inside some sort of opencode "box" imo.
Acters commentedon Apr 14, 2026
It is a feature that Gemini CLI has, too.
Which I think is a goated feature because I can press tab and the "CTRL+C" will kill the child shell command but not the actual Gemini CLI. Because sometimes the LLM runs a command that will wait for input or spawns a server that I need to kill or a script that is brute forcing a challenge that is going to take ages to actually solve, etc.
Complete pass through to the shell child running the LLM's command would be amazing for me.
For now, I tell the LLM to use TMUX to run commands in. That way I can connect to the TMUX session from a separate terminal and do what I need to do.
github-actions commentedon Jul 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.