Repository navigation
[FEATURE]:Interactive Shell Passthrough / Shared Pseudoterminal (pty) for MFA/auth/Cowork #53781
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
Right now, the OpenCode TUI handles shell execution as a strictly non-interactive process. If OpenCode tries to execute a shell tool or command that requires runtime interactive authentication (such as an SSH password prompt, an encrypted private key passphrase (Enter passphrase for key...), a sudo request, or an interactive MFA/OAuth login token hook) the session either hangs indefinitely or fails.
There is currently no native way for a user to "step into" the agent's running terminal buffer, type the password or complete the auth step, and let the agent continue.
Potential Solution Description
I would like to see an Interactive Passthrough Mode or a Shared Sub-Terminal Pane inside the OpenCode TUI.
When an agent-initiated bash command requests TTY/interactive input, OpenCode should:
- Detect the prompt pause (or let the user manually trigger an override).
- Expose or yield control of that specific pseudoterminal (
pty) screen directly to the user. - Allow the user to type in their password or verification code safely.
- Automatically pass execution control back to OpenCode seamlessly once the auth block is completed, letting the agent continue its automated workflow without breaking the session context, with the user able to see the terminal live.
Alternatives Considered
- Terminal Multiplexers (tmux/Zellij): Splitting windows manually and sharing environment variables. It works, but it breaks the unified, seamless experience of using the OpenCode TUI directly.
- Bypassing security: Using passwordless SSH keys is not always available on every system.
- Alternative Architectures: Platforms like AgentsRoom use a dedicated
ssh_connectloop that spawns a shared terminal window exactly for this coworker-auth paradigm, proving that the layout workflow is highly effective for pairing with agents, but adding a live terminal might enable user-agent cowork to be uch more efficient.
Activity
opencode-agent commentedon Oct 7, 2026
Thanks for the detailed request, @aptitudepi!
To restate it: when an agent-run shell command stops at an interactive prompt (sudo password, SSH key passphrase, MFA/OAuth code), you'd like OpenCode to hand that pty to you in the TUI so you can see it live and type the answer. Control would then go back to the agent without breaking the session. Right now the agent's shell commands run with stdin detached, so these prompts can't be answered and the command hangs or fails.
Maintainers will consider this. Related issues and discussions:
This can't be built as a plugin today. A plugin can't currently route the built-in shell tool through a PTY or show an interactive terminal pane in the TUI.
iceteaSA commentedon Oct 18, 2026
Part of this can already be built as a plugin on 2.x, for programs that accept an askpass helper instead of a TTY. We built one for sudo:
shelltool throughctx.tool.transformand rewrites elevated commands tosudo -A, withSUDO_ASKPASSpointing at a small helper.sudo -Kbefore and after every mediated call, so a warmed timestamp can't be reused by a later command that never went through the prompt. Second, refusingbackground: truefor these calls, because that cleanup has to run after the command exits. Matching the literal wordsudoisn't enough either (command sudo,env X=1 sudo,eval,xargsand friends), so the wrapper tokenizes the command and refuses forms it can't rewrite safely.The same helper covers more of the list in this issue:
SSH_ASKPASSplusSSH_ASKPASS_REQUIRE=force(OpenSSH 8.4+).GIT_ASKPASS.What it can't cover is anything that only reads from a TTY and has no askpass hook, such as MFA or one-time-code prompts in most CLIs. That still needs the passthrough described here.
Two smaller host gaps make the askpass route clumsier than it should be: the plugin prompt dialog has no masked input mode (#56747), and web/desktop have no plugin dialog at all (#43132), so on those clients the desktop password dialog is the only way to ask.