Repository navigation
[Feature] Allow the user to run their favorite shell in opencode #3228
Description
How about we allow ! commands to run the user's preferred shell in interactive mode?
Idea demo
demo.mp4
Brainstorm:
- Introduce a config variable called
shellor similar, which the user can set to any shell, e.g.bash,sh,fish - When the user types
!we start that shell (spawn a pty and attach that shell process to it) - The user types their commandline in that shell, presses enter, and the shell will execute the command
- We detect when the shell has finished running the command and kill it (see implementation idea below)
- The whole output is available to the LLM
Benefits:
- The user can have their *rc files applied for custom prompts etc
- The user can benefit from their shell's completions
- OC can benefit from the user's shell history
- I think this might be a panacea of a lot of potential feature requests (existing or future)
Bonus ideas:
- For some commands we might be able to detect if they are TUI-like commands and for those we can make sure they are displayed over the entire terminal window instead of just the small prompt box. I'm thinking
fzf. - We can even try to detect the PWD from the shell and when they
cdin the shell, also change the PWD of the OC session
Implementation idea for item no. 4
The easiest way I can think of is this:
- Introduce a command like
opencode shell prompt-startoropencode shell done - Instruct the user to modify their shell prompt so that it runs
opencode shell prompt-startwhen the prompt is displayed
(or alternatively, runopencode shell donein the shell's post-exec hook if supported (I'm a fish user and there you can use thefish_postexechook) - That command signals to the parent OC process that the shell command is done and opencode kills the shell
See also
This is heavily inspired by vterm.el and its handling of the shell. vterm.el (via libvterm) tracks the shell prompt and PWD through invisible OSC escape sequences printed by the shell itself, e.g. \e]51;Auser@host:/pwd\e\\. These sequences are injected at each prompt via a small shell function (like vterm_prompt_end) that’s called from the shell’s prompt hook (PROMPT_COMMAND in bash, fish_prompt in fish, etc.).
vterm.el listens for those sequences to precisely detect where the prompt ends and updates Emacs’ default-directory to match the shell’s current working directory.
Issues that could be addressed with this
I volunteer to implement this. TBH I'll prolly implement this in my fork in any case, but I'll wait for insights and ideas from the OC team :)
Activity
rekram1-node commentedon Oct 16, 2025
@veracioux i thought we already do that? If you "!" it reads the $SHELL value doesnt it
veracioux commentedon Oct 16, 2025
@rekram1-node Not quite what I meant. See the demo I just attached to the description.
rekram1-node commentedon Oct 16, 2025
Ahh i see yeah thats cool
rekram1-node commentedon Oct 16, 2025
whoopsie
it was literally your first sentence lmao:
veracioux commentedon Oct 16, 2025
@rekram1-node I added "interactive" after edit - so my fault :D
ArabianCowboy commentedon Mar 22, 2026
Feature Request: stdin Passthrough for Interactive Process Input (e.g., sudo passwords, SSH passphrases, confirmation prompts)
I'd like to highlight a specific sub-feature within the broader PTY discussion that I think deserves explicit attention: stdin passthrough during agent-executed commands.
Currently, when OpenCode runs a command that mid-execution requires user input — such as a sudo password prompt, an SSH passphrase, an npm login OTP, or a simple y/n confirmation — the process hangs and times out. There's no mechanism for the agent to detect that a process is waiting for input and hand control back to the user.
What the ideal behavior looks like:
Agent runs a command (e.g., sudo apt install ...)
The process writes a prompt to the terminal (e.g., [sudo] password for user:)
OpenCode detects the process is waiting for stdin
It surfaces the prompt to the user and accepts masked/raw input
The input is piped back to the running process and execution resumes
Precedents in other CLIs:
Gemini CLI implements this via node-pty + enableInteractiveShell, with a Ctrl+F to focus the interactive session
OpenAI Codex CLI handles this with a dedicated write_stdin tool that feeds keystrokes to a running PTY session
I also noticed that v1.2.21 already includes a fix(pty): pty session handle leak — which suggests PTY infrastructure is at least partially in the codebase. This might mean the remaining work to expose stdin passthrough is closer than it appears.
This isn't just a convenience — it's a blocker for any agentic workflow that touches system administration, authentication, or package management. Would love to see this scoped and tracked explicitly, even if it lands after the broader PTY work.
github-actions commentedon May 22, 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.