Before filing
Closest existing issue
#134 is about the built-in terminal's discoverability, not about choosing which terminal is used — none found for this specifically.
Is this new, or an improvement?
New capability — Berd can't do this at all today
The problem, in your terms
Berd sessions come with a built-in dockable terminal in the right rail, and it's always Berd's own terminal. My daily driver is Ghostty, with my own fonts, keybindings, scrollback behavior and shell setup. When I want to poke around a session's attached workspace, I end up wanting my real terminal there, not the embedded one — but there's no way to point Berd at it. As far as I can tell there's no setting to pick a terminal application, and no "open in external terminal" action on the workspace.
What you do today
Manually open Ghostty myself and cd to the workspace path (or ask the chat agent to run open -a Ghostty <path>). It works, but it's manual every time and completely disconnected from the workspace/terminal affordances Berd already has.
What you'd like to see
A setting like "Terminal application" (default: built-in), letting me pick an installed terminal — Ghostty, iTerm2, kitty, WezTerm, Terminal.app — so that the terminal affordances open my chosen app at the workspace path. If a full preference is too much, even a lightweight "Open in external terminal" action next to the built-in terminal (using the chosen or default app) would cover most of it.
Why this belongs in Berd itself
The terminal button and right-rail docking are app chrome — a skill or agent can run open -a Ghostty on request, but it can't change what Berd's own terminal affordance does, add an app-level setting, or make the choice persistent across sessions. Only the app can wire its terminal entry points to a user-chosen application.
Non-goals
- Not asking to remove or replace the built-in terminal — it should stay the default.
- Not asking to embed Ghostty (or any external emulator) inside the Berd window.
- Not asking for terminal-emulation feature parity in the built-in terminal; launching my external terminal at the right path is enough.
Alternatives you considered
- Asking the chat agent to launch Ghostty at the workspace path each time — works, but manual and invisible to Berd's UI.
- Living with the built-in terminal — usable, but it will never match a dedicated emulator's configuration, and that's fine; that's what the external option is for.
Mockups, prior art, or other context
Prior art: VS Code's terminal.external.osxExec + "Open in External Terminal" command; JetBrains IDEs' configurable terminal; GitHub Desktop's choice of shell/editor. macOS has no OS-level "default terminal" concept, which is exactly why apps offer this setting themselves.
Before filing
Closest existing issue
#134 is about the built-in terminal's discoverability, not about choosing which terminal is used — none found for this specifically.
Is this new, or an improvement?
New capability — Berd can't do this at all today
The problem, in your terms
Berd sessions come with a built-in dockable terminal in the right rail, and it's always Berd's own terminal. My daily driver is Ghostty, with my own fonts, keybindings, scrollback behavior and shell setup. When I want to poke around a session's attached workspace, I end up wanting my real terminal there, not the embedded one — but there's no way to point Berd at it. As far as I can tell there's no setting to pick a terminal application, and no "open in external terminal" action on the workspace.
What you do today
Manually open Ghostty myself and
cdto the workspace path (or ask the chat agent to runopen -a Ghostty <path>). It works, but it's manual every time and completely disconnected from the workspace/terminal affordances Berd already has.What you'd like to see
A setting like "Terminal application" (default: built-in), letting me pick an installed terminal — Ghostty, iTerm2, kitty, WezTerm, Terminal.app — so that the terminal affordances open my chosen app at the workspace path. If a full preference is too much, even a lightweight "Open in external terminal" action next to the built-in terminal (using the chosen or default app) would cover most of it.
Why this belongs in Berd itself
The terminal button and right-rail docking are app chrome — a skill or agent can run
open -a Ghosttyon request, but it can't change what Berd's own terminal affordance does, add an app-level setting, or make the choice persistent across sessions. Only the app can wire its terminal entry points to a user-chosen application.Non-goals
Alternatives you considered
Mockups, prior art, or other context
Prior art: VS Code's
terminal.external.osxExec+ "Open in External Terminal" command; JetBrains IDEs' configurable terminal; GitHub Desktop's choice of shell/editor. macOS has no OS-level "default terminal" concept, which is exactly why apps offer this setting themselves.