anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[Feature] Allow the user to run their favorite shell in opencode #2137

New Issue
Open
opened 2026-02-16 17:34:20 -05:00 by yindo · 5 comments
yindo commented 2026-02-16 17:34:20 -05:00
Owner
Copy Link
Copy Source

Originally created by @veracioux on GitHub (Oct 16, 2025).

Originally assigned to: @thdxr on GitHub.

How about we allow ! commands to run the user's preferred shell in interactive mode?

Idea demo

https://github.com/user-attachments/assets/84875c76-9419-464c-a350-1587cc21070a

Brainstorm:

  1. Introduce a config variable called shell or similar, which the user can set to any shell, e.g. bash, sh, fish
  2. When the user types ! we start that shell (spawn a pty and attach that shell process to it)
  3. The user types their commandline in that shell, presses enter, and the shell will execute the command
  4. We detect when the shell has finished running the command and kill it (see implementation idea below)
  5. 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 cd in 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-start or opencode shell done
  • Instruct the user to modify their shell prompt so that it runs opencode shell prompt-start when the prompt is displayed
    (or alternatively, run opencode shell done in the shell's post-exec hook if supported (I'm a fish user and there you can use the fish_postexec hook)
  • 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 :)

Originally created by @veracioux on GitHub (Oct 16, 2025). Originally assigned to: @thdxr on GitHub. How about we allow `!` commands to run the user's preferred shell in interactive mode? # Idea demo https://github.com/user-attachments/assets/84875c76-9419-464c-a350-1587cc21070a # Brainstorm: 1. Introduce a config variable called `shell` or similar, which the user can set to any shell, e.g. `bash`, `sh`, `fish` 2. When the user types `!` we start that shell (spawn a pty and attach that shell process to it) 3. The user types their commandline in that shell, presses enter, and the shell will execute the command 4. We detect when the shell has finished running the command and kill it (see implementation idea below) 5. 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 `cd` in 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-start` or `opencode shell done` - Instruct the user to modify their shell prompt so that it runs `opencode shell prompt-start` when the prompt is displayed (or alternatively, run `opencode shell done` in the shell's post-exec hook if supported (I'm a fish user and there you can use the `fish_postexec` hook) - 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 - https://github.com/sst/opencode/issues/3212#issuecomment-3412627160 --- 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 :)
yindo commented 2026-02-16 17:34:20 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

@veracioux i thought we already do that? If you "!" it reads the $SHELL value doesnt it

@rekram1-node commented on GitHub (Oct 16, 2025): @veracioux i thought we already do that? If you "!" it reads the $SHELL value doesnt it
yindo commented 2026-02-16 17:34:20 -05:00
Author
Owner
Copy Link
Copy Source

@veracioux commented on GitHub (Oct 16, 2025):

@rekram1-node Not quite what I meant. See the demo I just attached to the description.

@veracioux commented on GitHub (Oct 16, 2025): @rekram1-node Not quite what I meant. See the demo I just attached to the description.
yindo commented 2026-02-16 17:34:20 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

Ahh i see yeah thats cool

@rekram1-node commented on GitHub (Oct 16, 2025): Ahh i see yeah thats cool
yindo commented 2026-02-16 17:34:20 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

whoopsie

it was literally your first sentence lmao:

interactive mode?

@rekram1-node commented on GitHub (Oct 16, 2025): whoopsie it was literally your first sentence lmao: > interactive mode?
yindo commented 2026-02-16 17:34:20 -05:00
Author
Owner
Copy Link
Copy Source

@veracioux commented on GitHub (Oct 16, 2025):

@rekram1-node I added "interactive" after edit - so my fault :D

@veracioux commented on GitHub (Oct 16, 2025): @rekram1-node I added "interactive" after edit - so my fault :D
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2137
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?