"Command Finished" Notifications

[lishaduck]

I tried out Ghostty last night on my mac and was blown away. I love it :)
I know features at at "N" on the todo list and I certainly find Windows support more important, but I think this one shouldn't be awful to implement given that Ghostty already has the notifications entitlement and shell integration features, so here's the pitch:

When using Warp, if you don't have it in focus when a command finishes (or needs a password prompt), Warp will send you a notification. This is really helpful when using a separate terminal in the background, especially when using what Ghostty terms (pun unintended) "quick" terminals that disappear when unfocused. I usually use the vscode integrated terminal (can't wait for someone crazy to write an extension to use libghostty!), so I primarily use a separate terminal emulator for stuff like Homebrew, which I then run in the background, and inevitably forget about.

[00-kat]

Kitty also does this, and the way they have their configuration for this may be of interest.

[jasisk]

This can be accomplished with OSC 9 or OSC 777 (precedent), both of which ghostty supports. Examples (using sleep 5 to simulate a long running process and to give time to change window focus):

$ sleep 5; echo -e "\033]777;notify;your title;your body\007"
$ sleep 5; echo -e "\033]9;your body\007"

[lishaduck]

Yes, I'm aware that Ghostty supports notifications, but sending the notifications specifically when away requires info about window focus, which isn't easily available from the shell.
I could write a script to run it after each brew, etc, invocation, but that's still too noisy (and requires hardcoding what I'll leave behind), so I think it's better handled as part of the emulator as opposed to the shell.

[kevincox]

Neither of these seem to work for me. Maybe not supported on Linux?

[jcollie]

On Linux, you have to launch Ghostty from a .desktop file (well that's a bit of a simplification) or your DE won't allow notifications from Ghostty.

[kevincox]

Ah yes. That was the problem. Thank you very much. This is wonderful!

[DevTGhosh]

Number 1 feature I require as well. I have a couple of commands that take 15+ mins to work having a notification when it is done or if more info is required will be a godsend. Only reason I have been using warp for so long.

[nbCloud91]

Yes, this would be a useful feature to have. BlackBox which fits very well with GNOME has this.

[k8ieone]

GNOME Console (kgx) does this by default. If the terminal window is not focused and a command finishes running, it will send you a desktop notification. One of my favorite features.

[fonzai]

Warp also does this out-of-the-box. It's a really useful feature.

[Overload119]

zsh-notify also has this, I stumbled on this thread while looking for a replacement for it.

[pluiedev]

I like this idea, but we need to gather more concrete design ideas first.

[00-kat]

I wanted to mention, though I have no qualms on what the exact text of the notification would be, it would be nice if it contained the command (perhaps only the command name and not the entire command-line) that just finished.

[benyamynbrkyc]

This would be amazing! I run some docker builds that take quite a bit of time, and often leave them running in the background and forget about them. Love ghostty, it would be even better if this gets implemented

[lytedev]

I'd love to have an issue with this enhancement to track against. Does one exist? Should we create one?

Ideally I'd like something similar to WezTerm's options here: https://wezterm.org/config/lua/config/notification_handling.html

SuppressFromFocusedPane - Show the notification unless it was generated from the currently focused pane
SuppressFromFocusedTab - Show the notification unless it was generated from the currently focused tab
SuppressFromFocusedWindow - Show the notification unless it was generated from the currently focused window

Personally, the only one I'd use is SuppressFromFocusedTab, as if it's a focused tab (and therefore window) then I will see my prompt show up as the command finishes. Also happy to potentially contribute if the maintainers here agree this is a worthwhile addition!

[00-kat]

I'd love to have an issue with this enhancement to track against. Does one exist? Should we create one?

https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#issues-are-actionable and #3558.

This discussion has the “feature design” label:

From its description:

Thus, it can be concluded that this discussion is an accepted feature request but more discussion needs to be done on how it should be implemented.

[lishaduck]

https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#issues-are-actionable

Beat me to it :)

it can be concluded that this discussion is an accepted feature request

I missed that this semi-accepted. Exciting 🚀

[00-kat]

I missed that this semi-accepted. Exciting 🚀

It's pretty hard to notice that actually (you have to either hover over every label or read the page on labels), I only know because Mitchell mentioned it once in #development on the Discord.

[lytedev]

Thanks for pointing out those details!

As far as the design of the feature, what do you all think about having options similar to WezTerm?

Right now, we have desktop-notifications = true which simply indicates that the OSC 9 or OSC 777 escape sequences will cause Ghostty to show a desktop notification.

Similar to WezTerm, we could add a notification-handling-method flag with these options copied nearly verbatim:

• AlwaysShow - Show the notification regardless of the current focus
• SuppressFromFocusedPane - Show the notification unless it was generated from the currently focused pane
• SuppressFromFocusedTab - Show the notification unless it was generated from the currently focused tab
• SuppressFromFocusedWindow - Show the notification unless it was generated from the currently focused window

I removed "NeverShow" since you would instead simply set desktop-notifications = false in that case as far as I understand.

I think this would work without being terribly difficult to implement and provide enough flexibility for folks to have this behave the way they want.

The only other approach I can think of is somehow having Ghostty expose this focus information to the shell (at all times?) so that the shell itself can decide whether or not to echo the escape sequences, but I'm not sure of a lightweight way to do that, as it would involve an RPC or some kind of state or socket, both of which seem heavier and less in-line with Ghostty's philosophies (though admittedly I am not super close to the project).

[jcollie]

Here's what I'm thinking about for config:

notify-on-command-finish = never | unfocused | always
notify-on-command-finish-action = bell , no-notify
notify-on-command-finish-after = 5s

I think that ought to cover what most people want without getting too crazy.

[lishaduck]

I'm a bit lost on what the notify-on-command-finish-action is for. Is it that if it's set, it'd inherit e.g. the terminal bell setting?

Otherwise, that looks like that'd be more than sufficient for my use case!

[jcollie]

Basically notify-on-command-finish-action lets you choose between a bell (which could be audio) or a desktop notification. If you enabled bell the bell-features setting would control what happens next.

[mitchellh]

I accept this feature design.

If we implement this as a generic apprt action (I'm sure you will) that takes the action as a parameter, then we can easily enhance this in the future to manual per-command subscriptions, too. For example, right clicking the terminal and saying "notify when the next command finishes". I wouldn't do THAT in the same PR, but as long as we build the apprt action right that should be easy later.

[jzabroski]

Interested in doing a PR to support this. Missed that this is solved via #3555 (comment) #8991

For example, right clicking the terminal and saying "notify when the next command finishes". I wouldn't do THAT in the same PR, but as long as we build the apprt action right that should be easy later.

Yes, and... would allow filtering to just claude.exe, codex.exe, copilot.exe. For people who switch across harnesses and want toaster notifications across tabs. Assumption being people do not mess with the default terminal configs for each CLI e.g. https://code.claude.com/docs/en/terminal-config

The related UX affordance would be to hot-key switch to the notification in focus, which was completed after this design was accepted - #9145

[jcollie]

#8991

[jcollie]

@nbCloud91 please start a new discussion to troubleshoot problems that you may be having with this feature.