terminal activity indicator/alert when in background

Problem:
Often times there's a command invoked on the shell prompt that's long running and takes a while, and the user switches to a different window and puts the terminal window in the background while waiting for this command/job to complete. When the job completes, user is unaware this happened until the terminal window is switched back to (foreground) or user periodically peeks to see if the job has completed.

Suggestion:
If there can be some some sort of visual indicator or alert when there is terminal activity to suggest there is new output logged into the terminal, it would provide a cue to the user that the job may be complete. If the long running job happens to continually output to the terminal this wouldn't be as useful, but most times there's a job that runs for an unpredictable amount of time and then terminal returns to the prompt.

The indicator could be a temporary flashing of the window title in the task bar, and/or a change to a different shade/color until user has acknowledged the alert. Or may be display a badge on the title bar.

Alternatives considered that are not viable or great:

use unix terminal bell (I couldn't get this to work reliably while ssh'ed into different servers), also this requires user have the sound/headphones on, and is a one time event that if the user can miss (when the bell is rung), or if there are multiple windows there is no indication as to which window/pane is the one beeping.
use some type of window pop up (would require X or some such windowing to accomplish this, and not native to terminal).
notification systems similar to growl/notifier/etc (in MacOS) or even the Windows notification are not accessible while ssh'ed into a remote server where such long running command is run.

Terminal output based activity detection and alert seems native and logical place to do this without relying on any other system features.

maintainer edit: spec here

James Holderness (@j4james)

James Holderness (@j4james) Mike Griese (@zadjii-msft),
Here I suggested a terminal output/activity based alert mechanism. This detection will be so native to the terminal, the user doesn't have to explicitly say "notify me when done" or in cases when the user may not have had a chance to say "notify me" (user didn't anticipate/predict the command to take long to finish), and yet wants to see a notification.
Using terminal output activity as the trigger will mean it will work on both local and remote (ssh) sessions.
#7718 while similar seems to be a slightly different use case where the user explicitly has to request to be notified via the OSC. I think both use cases have their place. The output based notification falls flat when there the long running command is continually spewing output.
Thanks.

I don't use a mac, but it seems iterm has a feature like this based on this information in this post. I've seen it in one other terminal emulator as well (SecureCRT I think).

So, if this was to be implemented, and someone were to run something like a build that was displaying output constantly, wouldn't the indicator just be perpetually on? I don't really see the value in that, so there would have to be some sort of contextual way to enable/disable this.

Though I guess reading that post, the indeterminate progress wheel as the indicator kinda makes sense - then the wheel stopping spinning would be the indicator that the process stopped running. My only great disappointment is there's not a good way for the terminal to display that indicator in the taskbar icon. We could easily add the indicator to the tab itself, but that would only be visible if the window was visible. (see also #3991)

I personally think that this is better served by a combo of #3004 and having the client application emit the corresponding sequence.

Maybe we could combine the activity spinner with the indeterminate taskbar state. Add a setting to allow the user to show indeterminate state in the taskbar while the indicator is active. We'd probably want that to be overridden by whatever the client sets from the VT sequences as described in #3004, but that's not out of the realm of possibility. Obviously we'll want a setting both for enabling/disabling the indicator at all, and then a second one(?) for mirroring the indicator to the taskbar. That would only work if the "in progress" pane is the active pane, but that's good enough for most use cases I'd bet.

The longer I think about this, the more I've gone from "this seems ridiculous" to "we need to have this"

Impressive how you are able to keep these "related" issues in the head and can call out at will and tie them together :-)
It's a very useful feature IMHO (shamelessly plugging my request again).

In terms of usage, one could slice the end user requirement/experience in a couple of ways:

a long running command that continually spews output (such as a build), versus, commands that run for a while without outputting anything but when they end, terminal returns to the prompt. And in both cases having the terminal activity indicated to the user in some form is useful depending on the use case, the latter being more useful scenario.
user knows ahead of time and explicitly requests an alert, to be notified, at the end of the long running command, versus running a command that the user is oblivious to how long the command will take to complete, or didn't expect for it to take long when launching the command unsuspectingly but wants to be notified of the status in the background.

It seems the UI options you've suggested above covers both (or all 4) cases - please correct me if I'm wrong.

Thanks as always.

Both tmux and GNU Screen have a "silence" feature that notifies the user when there has been no new output for some time. In GNU Screen, the default is 30 seconds if enabled.

Scorpius (@naikel)

How about something like this? A little dot appears next to the tab's title once new output was received and the tab is in the background.

I also like Scorpius (@naikel)'s suggestion: I guess this could be configurable.

Having no way to tell something has changed is a real problem: I have to switch tabs myself from time to time to see if something happened: I shouldn't have to do that.

Is this being worked on? Or is there any plugin or alternative to achieve this?

Is this being worked on?

Nope, not yet. We haven't really settled on a design for this feature yet. Do you have a particular design in mind?

Rereading this thread, I think I like the design in #7955 (comment) the most myself. Kinda like the tab bell notification we have currently when an inactive tab BELs, but, just for any output.

Maybe something like: https://learn.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#bell-notification-style

notifyOnInactiveOutput:

taskbar: if the window is inactive and any tab receives new output, flash the taskbar
audible: if an inactive tab has new output, emit an audible bell (This will use the sounds from bellSounds, if specified)
tab: if an inactive tab has new output, just display an icon in the tab (ala terminal activity indicator/alert when in background #7955 (comment) )
~~window~~: this one doesn't make sense for an inactive window
notification: send a desktop notification if an inactive tab recieves output?

and these can be combined with each other, like the bell settings.

of course, notifyOnInactiveOutput is a gross setting name, but it's a start. Thoughts?

In another thread, I believe there was discussion of notifyOnNextPrompt, driven by shell integration. I think both are probably valuable, though "next output" is strictly a superset of "next prompt". That was in #6372.¹.

I suppose window kinda does work for notifyOnNextPrompt though. Hmm.

Okay, more official spec:

"OutputNotificationStyle": {
  "oneOf": [
    {
      "type": "boolean"
    },
    {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "taskbar",
          "audible",
          "tab",
          "notification"
        ]
      }
    },
    {
      "type": "string",
      "enum": [
        "taskbar",
        "audible",
        "tab",
        "notification"
        "all",
        "none"
      ]
    }
  ]
},

// ...

"Profile": {
  "properties": {
    // ...
    "notifyOnInactiveOutput": {
      "$ref": "#/$defs/OutputNotificationStyle",
      "default": "none",
      "description": "When this profile receives output in an inactive tab, raise a notification of the given type"
    },
    "notifyOnNextPrompt": {
      "$ref": "#/$defs/OutputNotificationStyle",
      "default": "none",
      "description": "When the commandline application returns to the prompt, raise a notification of the given type. This requires shell integration to be enabled."
    },

true -> "tab"

Try to combine with #1620, #8449. These are a pair of related scenarios:

"I want the terminal to show an indicator in the tab while a command is running"
- for an indicator, we can use an indeterminate progress ring
"I want the Terminal to show a progress ring based on the content of the last line of the buffer"

Proposal 1: not so good

"onInactiveOutput":
{
	"style": ["taskbar", "audible", "tab", "notification"],
    "progress": "default|automatic"
}

Eh, wait, I don't love that. Cause:

onInactiveOutput is an object, but notifyOnNextPrompt isn't (doesn't make sense to raise progress on the next prompt)
progress: automatic as a subset of onInactiveOutput implies that it wouldn't set progress if the tab was active

proposal 2

I think we can combine these to some setting that tells the control to report "progress" even if no progress was set:

disabled: don't do this
automatic: if we got a FTCS_COMMAND_EXECUTED (133;C), then any output, set our progress state to indeterminate
progress: walk+check the last line of the buffer: if it's got {(\d)%, (\d)/(\d)} in it, then use that number instead

"autoDetectRunningCommand": "disabled|automatic|progress"

NOTES:

If we do "autoDetectRunningCommand": "automatic", progress rings take precedence over the tab icon. So notifyOn* would need to be a separate icon.
"autoDetectRunningCommand": "automatic" should end on a prompt mark
"autoDetectRunningCommand": "automatic" should not do the thing on ONLY inactive/hidden panes

hackathon 2023 notes:

dev/migrie/fhl-fall-2023/3991-progress-before-connection -> Use an indeterminate progress ring on the tab before a tab is "connected" #3991
- dev/migrie/fhl-fall-2023/1620-automatic-tab-progress -> Add a "tab busy indicator" to show when a tab has belled or has output #1620

"autoDetectRunningCommand": "automatic" PoC:

Something's sorta wrong when a connection first starts. dir also leaves the progress state polluted, even without shell integration

I should really pick one of these as the thread and close the other as a dupe. ↩

notification: send a desktop notification if an inactive tab recieves output?

Is this a toast notification or some thing like that? If yes, perhaps it can show the window title and any other useful info in it, and when clicked on the notification could switch to the window (raise to foreground) that the notification is for?
Thanks.

note to self: an example of the notification style:

598c839eea0d975f.1.mp4

credit:
https://mastodon.social/@raggesilver/110045050437013369

Scorpius (@naikel)

I know probably this is not what you guys wanted but here's my version of something similar if a non-focused tab has new output:

Scorpius (@naikel) This is the exact thing I want, can you please explain how you enabled this and which unix terminal you are using?

maddishah

maddishah at the time I modified the source code of this project for that, but I never send a pull request for it because it seemed nobody liked the design for it.

It's long gone now.

This functionality is very useful for long running tasks, and works extremely well with Git Bash's MINGW64 terminal, such that

sleep 5 && tput bel

Will bring the window back into focus once it's completed even if it was previously minimized.

This might be a bit of a different use case, but the bell behaviour is more direct in that the program requires focus or attention of some kind, and the user should react accordingly.

The behaviour is also configurable here:

Just passing to say that I've been working with computers for over 30 years.

And, throughout that time, I've often dreamed of having something like this.

Especially... right now, as I wait for a long build task to finish.

I'm eager to see this one become a reality!

I also need feature like https://unix.stackexchange.com/questions/617889/is-there-a-terminal-emulator-which-can-notify-when-there-is-an-output-with-certa .

Best way to show your support for this issue is by 👍'ing it - that's generally how we track priority around these parts.

(I also want you to do that because I want this feature too so I want all the excuses possible to work on it 😆)

I would like this feature as well please. 👍

If this flashing/color-change state can be triggered programmatically (e.g., via a terminal bell or a dedicated escape sequence), it would also be useful for AI coding agents that need to request user attention.

I've been using Ghostty in macOS that does this with OSC 133;C and OSC 133;D in bash and other supported shells. I'm working on pwsh support now.

Basically, your pre-prompt ($PS0 in bash, $function:PSConsoleHostReadLine in pwsh) needs to send OSC 133;C e.g.,

"`e]133;C;cmdline_url=$([Uri]::EncodeUriString($the_command))`a" # cmdline_url is the standard and optional, but "cmdline" variations are common

Your prompt ($PS1 in bash, $function:prompt in pwsh) needs to send OSC 133;D e.g.,

"`e]133;D;$LASTEXITCODE`a" # optional exit code, though you'd want to capture it probably because it often gets overwritten

You measure the time between OSC 133;C and OSC 133;D and, when above some user-defined threshold (perhaps profile-based, so a default could be specified but overridden per-profile) and show a system notification when that threshold is crossed with the URI-decoded cmdline_url.

Navigation Menu

Repository navigation

terminal activity indicator/alert when in background #7955

14 remaining items

proposal 2

NOTES:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

terminal activity indicator/alert when in background #7955

Description

Activity

damnskippy commented on Oct 19, 2020

damnskippy commented on Oct 19, 2020

zadjii-msft commented on Oct 21, 2020

damnskippy commented on Oct 21, 2020

KalleOlaviNiemitalo commented on Oct 23, 2020

14 remaining items

warpdesign commented on Oct 7, 2022

max-programming commented on Nov 4, 2022

zadjii-msft commented on Nov 4, 2022

proposal 2

NOTES:

Footnotes

damnskippy commented on Nov 5, 2022

zadjii-msft commented on Mar 23, 2023

maddishah commented on May 14, 2024

naikel commented on May 14, 2024

codebymikey commented on Jul 11, 2024

fdcastel commented on Oct 25, 2024

xgdgsc commented on Dec 2, 2024

zadjii-msft commented on Dec 2, 2024

etxaleku commented on Sep 18, 2025

kimsey0 commented on Jan 21, 2026

heaths commented on Mar 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions