Desktop: Run button for shell code blocks in chat (like Claude Desktop) #60875

Activity

1. opencodejr commented on Oct 31, 2026

   

   opencodejrBot

   on Oct 31, 2026

   More actions

   Thanks for the suggestion, @Alex046! You're asking for a Run (▶) button on shell code blocks (bash/sh/zsh/fish) in Desktop chat messages. It would run the command through the session shell, keep the Run and copy buttons always visible, and expand the shell output automatically. Maintainers will consider it.

   Related items:

   • feat(session-ui): add run button for shell code blocks #59810: the earlier PR that implemented this through the session.shell API. The compliance bot closed it because the description didn't follow the PR template, not because of its content.
   • feat(session-ui): keep the code block copy button in view while scrolling #59159: keeps the code block copy button in view while scrolling (same code block UI).
   • feat(session-ui): add a copy button to shell output #58974: adds a copy button to shell output.

   This can't be built as a Desktop plugin today, because the GUI plugin SDK has no way to add buttons to code blocks in the chat.
2. ryanmeador commented on Nov 4, 2026

   

   ryanmeador

   on Nov 4, 2026

   More actions

   With #61533 merged, I’d like to implement Run in terminal through CodeBlockAction in the built-in terminal plugin.

   Proposed behavior:

   • Clicking Run sends the completed shell code block, followed by Enter, to the session’s currently selected terminal and opens/focuses its tab.
   • Create a terminal only if the session has none.
   • Preserve the terminal’s current working directory and shell state. No directory changes, busy detection, or automatic switching to another terminal: this sends input as if the user pasted the command and pressed Enter.

   This targets the interactive terminal panel, not session.shell output in the conversation.

   This proposal covers desktop and web, using their shared built-in terminal plugin. A corresponding TUI action would be a separate follow-up.

   Is anyone already working on this, and would maintainers approve this approach before implementation?