Feature Request: command or proprietary escape codes to set a tab&#39;s color #9117

@zadjii-msft commented on GitHub (Jun 18, 2020):

Why the heck is that sequence formatted that way? Why isn't it just ^[]6;1;r;g;b^G?

I mean I'm generally fine with the idea, but I'd just imagine that they would have designed a better sequence tbh. What happens when you only emit

echo -e "\033]6;1;bg;red;brightness;255\a"

?

I could see this being useful as another alternative to #3004, where an app could change the tab color as a kind of notification.

@zadjii-msft commented on GitHub (Jun 18, 2020): Why the heck is that sequence formatted that way? Why isn't it just `^[]6;1;r;g;b^G`? I mean I'm generally fine with the idea, but I'd just imagine that they would have designed a better sequence tbh. What happens when you only emit ``` echo -e "\033]6;1;bg;red;brightness;255\a" ``` ? I could see this being useful as another alternative to #3004, where an app could change the tab color as a kind of notification.

claunia commented

@DHowett commented on GitHub (Jun 19, 2020):

I'm alright committing this to the backlog w/ Help Wanted. Yanking triage.

@DHowett commented on GitHub (Jun 19, 2020): I'm alright committing this to the backlog w/ Help Wanted. Yanking triage.

claunia commented

@j4james commented on GitHub (Jun 19, 2020):

I believe this originally came from Eterm, which is why it doesn't share the typical XTerm color syntax. And to be honest, I'd probably recommend coming up with our own sequence if we want to support this functionality (or at least looking for an alternative that other terminals might be using). I can't see OSC 6 ever being widely used, because it already has at least two other meanings. In XTerm it's used to enable special colors. In Terminal.app and VTE it's used to set the current file path.

@j4james commented on GitHub (Jun 19, 2020): I believe this originally came from Eterm, which is why it doesn't share the typical XTerm color syntax. And to be honest, I'd probably recommend coming up with our own sequence if we want to support this functionality (or at least looking for an alternative that other terminals might be using). I can't see OSC 6 ever being widely used, because it already has at least two other meanings. In XTerm it's used to enable special colors. In Terminal.app and VTE it's used to set the current file path.

claunia commented

https://i.imgur.com/8ujq0uN.jpg

@j4james commented on GitHub (Aug 13, 2020):

I had an idea for a sequence we could possibly use for this. On the DEC VT525, there's a DECAC (Assign Color) control sequence which is used to set the default foreground and background colors (essentially the equivalent of the XTerm OSC 10 and OSC 11 sequences). But it can also be used to set the Window Frame color, which I think could be considered somewhat equivalent to our tabs.

The VT525 has a concept of multiple sessions, and when the Frame Windows option is selected, a row of icons is displayed across the top of the screen to keep track of the different sessions, very similar in concept to tabs. You can see an image of a VT520 screen showing the session icons here:

The second session isn't named in that image, so it's not that obvious that you've got two sessions, but you can still see how similar those session identifiers are to tabs. This particular image is from a monochrome device, but I believe both the window frame and the icons would be displayed using the Window Frame colors, so I don't think it would be unreasonable for us to also use those colors for our tabs.

@j4james commented on GitHub (Aug 13, 2020): I had an idea for a sequence we could possibly use for this. On the DEC VT525, there's a `DECAC` (Assign Color) control sequence which is used to set the default foreground and background colors (essentially the equivalent of the XTerm `OSC 10` and `OSC 11` sequences). But it can also be used to set the _Window Frame_ color, which I think could be considered somewhat equivalent to our tabs. The VT525 has a concept of multiple sessions, and when the _Frame Windows_ option is selected, a row of icons is displayed across the top of the screen to keep track of the different sessions, very similar in concept to tabs. You can see an image of a VT520 screen showing the session icons here: https://i.imgur.com/8ujq0uN.jpg The second session isn't named in that image, so it's not that obvious that you've got two sessions, but you can still see how similar those session identifiers are to tabs. This particular image is from a monochrome device, but I believe both the window frame and the icons would be displayed using the _Window Frame_ colors, so I don't think it would be unreasonable for us to also use those colors for our tabs.

claunia commented

2026-01-31 01:46:30 +00:00

@j4james commented on GitHub (Aug 13, 2020):

Although now that I'm rereading the documentation, I realise you can only specify a color index when setting these colors. And technically the VT525 only supported index values in the range 0 to 15, but we could probably support all 256 colors from the XTerm color table and still be backwards compatible. But if you were hoping to be able to specify a full RGB value, then this isn't quite what you want.

@j4james commented on GitHub (Aug 13, 2020): Although now that I'm rereading the documentation, I realise you can only specify a color index when setting these colors. And technically the VT525 only supported index values in the range 0 to 15, but we could probably support all 256 colors from the XTerm color table and still be backwards compatible. But if you were hoping to be able to specify a full RGB value, then this isn't quite what you want.

claunia commented

2026-01-31 01:46:30 +00:00

@sba923 commented on GitHub (Jan 26, 2021):

Just wondering: is the only reason why this is stalling that there's no agreement on what the escape sequence should be?

@sba923 commented on GitHub (Jan 26, 2021): Just wondering: is the only reason why this is stalling that there's no agreement on what the escape sequence should be?

claunia commented

2026-01-31 01:46:30 +00:00

@j4james commented on GitHub (Jan 26, 2021):

Personally I'm quite keen to implement the DECAC sequence (assuming that's something the core devs would be happy to accept), just because I'd like for us to support as many of the standard DEC sequences as possible. I don't know if that would necessarily satisfy those of you that requested this functionality, though.

So while I'm not exactly waiting for agreement on a sequence (I'd probably submit a PR for DECAC at some point anyway), the fact that nobody seemed interested in my proposed solution made me think it wasn't worth prioritizing.

@j4james commented on GitHub (Jan 26, 2021): Personally I'm quite keen to implement the `DECAC` sequence (assuming that's something the core devs would be happy to accept), just because I'd like for us to support as many of the standard DEC sequences as possible. I don't know if that would necessarily satisfy those of you that requested this functionality, though. So while I'm not exactly waiting for agreement on a sequence (I'd probably submit a PR for `DECAC` at some point anyway), the fact that nobody seemed interested in my proposed solution made me think it wasn't worth prioritizing.

claunia commented

@zadjii-msft commented on GitHub (Jan 26, 2021):

It's probably 50% "no agreement on what the sequence should be" and 50% "there's just not enough demand for us to bother figuring it out".

Using OSC 6 is a bad idea because it's used for other things. DECAC is no good either? ~~So we'd have to come up with our own sequence, and frankly we just haven't done that yet. So this would be setting a precedent in that regard, and isn't something we'd want to do wrong.~~

~~In previous issues we've mentioned using the OSC prefix ^[]9001 for WT-specific sequences, and I'm still down with that. So this would be something like ^[]9001;1;r;g;b~~

As I'm typing this up I see j4james's reply. I'm fine with the DECAC solution if he is. He's got a better head for what is or isn't compatible.

I think mostly, there's just not that much priority on such a feature. I think most people have been doing alright with the "set tab color" actions and right click menu, so this just hasn't bubbled up the task list.

@zadjii-msft commented on GitHub (Jan 26, 2021): It's probably 50% "no agreement on what the sequence should be" and 50% "there's just not enough demand for us to bother figuring it out". Using OSC 6 is a bad idea because it's used for other things. `DECAC` is no good either? ~~So we'd have to come up with our own sequence, and frankly we just haven't done that yet. So this would be setting a precedent in that regard, and isn't something we'd want to do _wrong_.~~ ~~In previous issues we've mentioned using the OSC prefix `^[]9001` for WT-specific sequences, and I'm still down with that. So this would be something like `^[]9001;1;r;g;b`~~ As I'm typing this up I see j4james's reply. I'm fine with the DECAC solution if he is. He's got a better head for what is or isn't compatible. I think mostly, there's just not that much priority on such a feature. I think most people have been doing alright with the "set tab color" actions and right click menu, so this just hasn't bubbled up the task list.

claunia commented

@sba923 commented on GitHub (Jan 26, 2021):

I think not being able to specify any RGB color would be quite a limitation / inconsistency with other colors being specified as RGB.

Just my €0.02.

About the priority: yes "set tab color" can be done, but what I'd like to get (and frankly I can't be alone, and those who don't upvote this should really reconsider their line of thinking) is the ability to set the color e.g. when I switch projects, when something special occurs within the tab, to show that some long-lasting command has completed.... etc.

@sba923 commented on GitHub (Jan 26, 2021): I think not being able to specify any RGB color would be quite a limitation / inconsistency with other colors being specified as RGB. Just my €0.02. About the priority: yes "set tab color" can be done, but what I'd like to get (and frankly I can't be alone, and those who don't upvote this should really reconsider their line of thinking) is the ability to set the color e.g. when I switch projects, when something special occurs within the tab, to show that some long-lasting command has completed.... etc.

claunia commented

@WSLUser commented on GitHub (Jan 27, 2021):

when something special occurs within the tab

Might want to check https://github.com/microsoft/terminal/issues/6700

@WSLUser commented on GitHub (Jan 27, 2021): > when something special occurs within the tab Might want to check https://github.com/microsoft/terminal/issues/6700

claunia commented

@sba923 commented on GitHub (Jan 27, 2021):

when something special occurs within the tab

Might want to check #6700

Interesting indeed, for instance the BEL detection.

Can't wait to have all this released 😆

@sba923 commented on GitHub (Jan 27, 2021): > > when something special occurs within the tab > > Might want to check #6700 Interesting indeed, for instance the BEL detection. Can't wait to have all this released 😆

claunia commented

@zadjii-msft commented on GitHub (Sep 13, 2021):

As noted in https://github.com/microsoft/terminal/issues/11181#issuecomment-918273715, there's an iTerm2 sequence for setting the tab color, which is a little weird but it's an OSC so of course it is. That's a seemingly unambiguous way of implementing this.

@zadjii-msft commented on GitHub (Sep 13, 2021): As noted in https://github.com/microsoft/terminal/issues/11181#issuecomment-918273715, there's an iTerm2 sequence for setting the tab color, which is a little weird but it's an OSC so of course it is. That's a seemingly unambiguous way of implementing this.

claunia commented

@zippygit commented on GitHub (Mar 6, 2022):

I've grown fond of using the functionality in iTerm2 when working from a Mac, via shell functions setting tab color based on keywords indicating what development host I'm logged into or other parameters. When I move to WSL and Windows Terminal for the same kind of work, I keep invoking the shell functions out of habit :). While those iTerm2 sequences are awkward, they are at least functional, and can be encapsulated once in shell functions/scripts, which may be the most common context for using them. Better sequence alternatives would also be OK, though the logic for determining on a remote host what kind of terminal emulator has logged into it could be unpleasant.

@zippygit commented on GitHub (Mar 6, 2022): I've grown fond of using the functionality in iTerm2 when working from a Mac, via shell functions setting tab color based on keywords indicating what development host I'm logged into or other parameters. When I move to WSL and Windows Terminal for the same kind of work, I keep invoking the shell functions out of habit :). While those iTerm2 sequences are awkward, they are at least functional, and can be encapsulated once in shell functions/scripts, which may be the most common context for using them. Better sequence alternatives would also be OK, though the logic for determining on a remote host what kind of terminal emulator has logged into it could be unpleasant.

claunia commented

@sba923 commented on GitHub (Mar 6, 2022):

Are you referring to the commands used at https://kendsnyder.com/tab-colors-in-iterm2-v10/?

Just tried this in WSL2 running within Windows Terminal Preview 1.13.10395.0, this doesn't change the tab's color...

Did I miss something?

@sba923 commented on GitHub (Mar 6, 2022): Are you referring to the commands used at https://kendsnyder.com/tab-colors-in-iterm2-v10/? Just tried this in WSL2 running within Windows Terminal Preview 1.13.10395.0, this doesn't change the tab's color... Did I miss something?

claunia commented

@zippygit commented on GitHub (Mar 6, 2022):

Are you referring to the commands used at https://kendsnyder.com/tab-colors-in-iterm2-v10/?

Just tried this in WSL2 running within Windows Terminal Preview 1.13.10395.0, this doesn't change the tab's color...

Did I miss something?

You didn't miss anything. They do not work in Windows Terminal (Preview or otherwise) today. Under discussion here was the idea of adding a feature to Windows Terminal so that they do work (or some other, similar but better escape sequences could be made to work in lieu of these).

@zippygit commented on GitHub (Mar 6, 2022): > Are you referring to the commands used at https://kendsnyder.com/tab-colors-in-iterm2-v10/? > > Just tried this in WSL2 running within Windows Terminal Preview 1.13.10395.0, this doesn't change the tab's color... > > Did I miss something? You didn't miss anything. They do not work in Windows Terminal (Preview or otherwise) today. Under discussion here was the idea of adding a feature to Windows Terminal so that they *do* work (or some other, similar but better escape sequences could be made to work in lieu of these).

claunia commented

2026-01-31 01:46:33 +00:00

@j4james commented on GitHub (Mar 6, 2022):

I actually had a plan for this that I've been meaning to propose, which doesn't require any proprietary sequences, but would still give you full RGB control of the color.

The idea is you'd use the DECAC sequence to control the palette index for the tab (as suggested above), but then set the actual RGB value of that palette entry with one of the existing palette control sequences: OSC 4 or DECRSTS (once I get around to adding that).

This would work the same way we now handle default foreground and background colors, with the new color alias system. So we'd create a new entry in the color table outside the base 256 range, and that's what the tab color would point to by default.

The simplest way to change the tab color would then be with a palette update sequence setting palette entry 258 (or whatever position we decide to assign to it). If you want to be more robust, though, you could lookup the actual index first with a DECRQSS query.

One of the neat benefits of this approach, is you also have the option of setting the tab color index to match the default background color index, and that way you'd have your tab automatically matching your background color (the UI concept proposed in #702).

@j4james commented on GitHub (Mar 6, 2022): I actually had a plan for this that I've been meaning to propose, which doesn't require any proprietary sequences, but would still give you full RGB control of the color. The idea is you'd use the `DECAC` sequence to control the palette index for the tab (as suggested above), but then set the actual RGB value of that palette entry with one of the existing palette control sequences: `OSC 4` or `DECRSTS` (once I get around to adding that). This would work the same way we now handle default foreground and background colors, with the new color alias system. So we'd create a new entry in the color table outside the base 256 range, and that's what the tab color would point to by default. The simplest way to change the tab color would then be with a palette update sequence setting palette entry 258 (or whatever position we decide to assign to it). If you want to be more robust, though, you could lookup the actual index first with a `DECRQSS` query. One of the neat benefits of this approach, is you also have the option of setting the tab color index to match the default background color index, and that way you'd have your tab automatically matching your background color (the UI concept proposed in #702).

claunia commented

@sba923 commented on GitHub (Mar 7, 2022):

I would not like a link between background color and tab color, 'cos I want to stick to my (dark grey) background color for my shells, yet I want to be able to easily tell tabs apart thanks to their color.

@sba923 commented on GitHub (Mar 7, 2022): I would not like a link between background color and tab color, 'cos I want to stick to my (dark grey) background color for my shells, yet I want to be able to easily tell tabs apart thanks to their color.

claunia commented

2026-01-31 01:46:33 +00:00

@zadjii-msft commented on GitHub (Mar 7, 2022):

Oh interesting, so it'd be like:

By default, the tab color would be set to something like index 258 in the color table.
You could set the tab color using DECAC to the color of the DARK_RED entry in the table (index 1), or the default BG color (index... 257?)
Alternatively, you could just change the tab color by setting index 258 directly with OSC4.

IMO that's a really clever, elegant solution.

As a sidebar, I actually think there's an API in Window 11 for setting the window frame color. So, we may want to actually extend DECAC here with additional parameters for frame, tab color, etc. I'll leave that best judgement to j4james though, since he's got a better knack for the compat concerns there.

note to self: DECAC docs (search for "DECAC—Assign Color"). Couldn't find a better source.

@zadjii-msft commented on GitHub (Mar 7, 2022): Oh interesting, so it'd be like: * By default, the tab color would be set to something like index 258 in the color table. * You could set the tab color using DECAC to the color of the DARK_RED entry in the table (index 1), or the default BG color (index... 257?) * Alternatively, you could just change the tab color by setting index 258 directly with OSC4. IMO that's a really clever, elegant solution. As a sidebar, I actually think there's an API in Window 11 for setting the window frame color. So, we may want to actually extend DECAC here with additional parameters for frame, tab color, etc. I'll leave that best judgement to j4james though, since he's got a better knack for the compat concerns there. note to self: [DECAC docs](http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf) (search for "DECAC—Assign Color"). Couldn't find a better source.

claunia commented

2026-01-31 01:46:33 +00:00

@ghost commented on GitHub (Jul 6, 2022):

:tada:This issue was addressed in #13058, which has now been successfully released as Windows Terminal Preview v1.15.186.🎉

Handy links:

@ghost commented on GitHub (Jul 6, 2022): :tada:This issue was addressed in #13058, which has now been successfully released as `Windows Terminal Preview v1.15.186`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.15.186) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@sba923 commented on GitHub (Jul 6, 2022):

We need documentation describing how to use the newly supported DECAC to set the tab's color.

So far, I've experimentally determined that ESC [ 2 ; 0 ; n , | will change the tab's color depending on n, but not what palette n indexes into, nor how to select a color by its RGB value.

@sba923 commented on GitHub (Jul 6, 2022): We need documentation describing how to use the newly supported `DECAC` to set the tab's color. So far, I've experimentally determined that `ESC [ 2 ; 0 ; n , |` will change the tab's color depending on `n`, but not what palette `n` indexes into, nor how to select a color by its RGB value.

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2022):

@sba923 It sure should! Filed https://github.com/MicrosoftDocs/Console-Docs/issues/267 to track.

@zadjii-msft commented on GitHub (Jul 6, 2022): @sba923 It sure should! Filed https://github.com/MicrosoftDocs/Console-Docs/issues/267 to track.

claunia commented

@DHowett commented on GitHub (Jul 6, 2022):

In short, though: DECAC can assign the frame and default indices each to any other color from the xterm 256-color palette (by index -- therefore, if you reassign what that index means, you can change that color no matter where it is used).

James' PR also added 263 and 264 as virtual indices that contain the tab foreground and background, respectively. You can change them using OSC 4. These are technically unrelated to DECAC[1].

So at runtime, you can change the tab color programmatically by setting the color table entry at index 262 (sic: I think he meant 264) using OSC 4 (assuming you need a specific RGB value). Otherwise if you just want to set the tab color to an existing color index, you can use DECAC 2.
@j4james in commit a69ce89712

Therefore, this will change the tab background color to any RGB value (OSC 4):

And this will change the tab background color to "whatever the background color of the Terminal is" (DECAC):

Our documentation should clarify these new color indices since we're making a contract out of them, and it should further clarify the purpose of DECAC specifically.

[1] Technically. They're related because you can use DECAC to reassign "frame colors" to any two indices instead of 263 and 264.

@DHowett commented on GitHub (Jul 6, 2022): In short, though: DECAC can assign the frame and default indices each to any _other_ color from the xterm 256-color palette (by index -- therefore, if you reassign what that index means, you can change that color no matter where it is used). James' PR also added `263` and `264` as virtual indices that contain the tab foreground and background, respectively. You can change them using OSC 4. These are technically unrelated to DECAC[1]. > So at runtime, you can change the tab color programmatically by setting the color table entry at index 262 (sic: I think he meant 264) using `OSC 4` (assuming you need a specific RGB value). Otherwise if you just want to set the tab color to an existing color index, you can use `DECAC 2`. > _@j4james in commit a69ce89712bc79e93820c5864dedacd48bad9ce6_ Therefore, _this_ will change the tab background color to any RGB value (`OSC 4`): <img width="392" alt="image" src="https://user-images.githubusercontent.com/189190/177624087-2bc4235a-37be-4b26-80ec-8588d38ed130.png"> And _this_ will change the tab background color to "whatever the background color of the Terminal is" (`DECAC`): <img width="306" alt="image" src="https://user-images.githubusercontent.com/189190/177624276-fc1c155b-f7d3-41ad-885b-33e7e7526f97.png"> Our documentation should clarify these new color indices since we're making a contract out of them, and it should further clarify the purpose of `DECAC` specifically. [1] Technically. They're related because you can use DECAC to reassign "frame colors" to any two indices instead of 263 and 264.

claunia commented

@sba923 commented on GitHub (Jul 6, 2022):

Thanks @DHowett for the short explanation. I'll keep experimenting.

@sba923 commented on GitHub (Jul 6, 2022): Thanks @DHowett for the short explanation. I'll keep experimenting.

claunia commented