WT should set COLORTERM #14987

@j4james commented on GitHub (Aug 31, 2021):

Woah, I've never seen that particular sequence (\eP$qm\e) used before.

I'm sure I have mentioned this before somewhere, but I'm convinced that just supporting DECRQSS and DECRQM would solve 99% of feature detection issues. Admittedly it's not always that straightforward to use, and I know a lot of people don't like terminal queries in general, but they're at least an existing standard that has a reasonable level of support amongst other terminals.

I actually have a partial DECRQSS implementation in a stash somewhere which might be worth resurrecting. I think I put it on hold because we didn't have the APIs in place to query all the settings that were needed, but maybe a partial implementation is still better than nothing.

That said, I am also in favor of a COLORTERM env, just because it's quite widely used, and I don't see any harm in it. I'm not so sure about TERM_PROGRAM, though, because that encourages apps to do the same stupid things that web developers did with user-agent strings, like writing code that refuses to run if the detected terminal isn't one that they recognise (this is not just hypothetical - I've seen it happening already).

@j4james commented on GitHub (Aug 31, 2021): > Woah, I've never seen that particular sequence (`\eP$qm\e`) used before. I'm sure I have mentioned this before somewhere, but I'm convinced that just supporting `DECRQSS` and `DECRQM` would solve 99% of feature detection issues. Admittedly it's not always that straightforward to use, and I know a lot of people don't like terminal queries in general, but they're at least an existing standard that has a reasonable level of support amongst other terminals. I actually have a partial `DECRQSS` implementation in a stash somewhere which might be worth resurrecting. I think I put it on hold because we didn't have the APIs in place to query all the settings that were needed, but maybe a partial implementation is still better than nothing. That said, I am also in favor of a `COLORTERM` env, just because it's quite widely used, and I don't see any harm in it. I'm not so sure about `TERM_PROGRAM`, though, because that encourages apps to do the same stupid things that web developers did with user-agent strings, like writing code that refuses to run if the detected terminal isn't one that they recognise (this is not just hypothetical - I've seen it happening already).

claunia commented

@DHowett commented on GitHub (Aug 31, 2021):

I'm not so sure about TERM_PROGRAM, though, because that encourages apps to do the same stupid things that web developers did with user-agent strings, like writing code that refuses to run if the detected terminal isn't one that they recognise (this is not just hypothetical - I've seen it happening already).

I felt like this for a while, but then I realized that we're fighting a losing battle against people who are looking for WT_SESSION or checking the process tree for WindowsTerminal.exe and lighting up features that would otherwise work fine in conhost only when they find it. For all the issues TERM_PROGRAM has, I suspect that it is only as bad as what folks are already doing. I don't know.

@DHowett commented on GitHub (Aug 31, 2021): > I'm not so sure about `TERM_PROGRAM`, though, because that encourages apps to do the same stupid things that web developers did with user-agent strings, like writing code that refuses to run if the detected terminal isn't one that they recognise (this is not just hypothetical - I've seen it happening already). I felt like this for a while, but then I realized that we're fighting a losing battle against people who are looking for `WT_SESSION` or checking the process tree for `WindowsTerminal.exe` and lighting up features that _would otherwise work fine in conhost_ only when they find it. For all the issues `TERM_PROGRAM` has, I suspect that it is only as bad as what folks are already doing. I don't know.

claunia commented

@heaths commented on GitHub (Aug 31, 2021):

TERM_PROGRAM would create the mess browsers had (have, really) for decades with UAs. Feature-level detection would be ideal, and without queuing up xkcd's strip on standards, TERM=xterm-256color seems pretty standard across most terminals while COLORTERM seems to be akin to a "v2" for TERM. The bigger question is what it should be set to. In some discussions, it seems having it set to anything at all should indicate at least 256 color support if not truecolor support.

If you'd set TERM_PROGRAM=WindowsTerminal or something like that, as a dev I'd still be tempted to use WT_SESSION because it's been around longer and supports more customers.

@heaths commented on GitHub (Aug 31, 2021): `TERM_PROGRAM` would create the mess browsers had (have, really) for decades with UAs. Feature-level detection would be ideal, and without queuing up xkcd's strip on standards, `TERM=xterm-256color` seems pretty standard across most terminals while `COLORTERM` seems to be akin to a "v2" for `TERM`. The bigger question is what it should be set to. In some discussions, it seems having it set to anything at all should indicate at least 256 color support if not truecolor support. If you'd set `TERM_PROGRAM=WindowsTerminal` or something like that, as a dev I'd still be tempted to use `WT_SESSION` because it's been around longer and supports more customers.

claunia commented

@Diablo-D3 commented on GitHub (Oct 13, 2021):

Side note for those who are following this ticket: https://github.com//termstandard/colors is the best documentation out there for what supports COLORTERM. Windows Terminal is already on this list, even though it isn't emitting the variable yet.

@Diablo-D3 commented on GitHub (Oct 13, 2021): Side note for those who are following this ticket: https://github.com//termstandard/colors is the best documentation out there for what supports COLORTERM. Windows Terminal is already on this list, even though it isn't emitting the variable yet.

claunia commented

@PennRobotics commented on GitHub (Jan 11, 2022):

oh-my-zsh changed their update script to use truecolor if supported. I had replaced the omz ASCII art and color definitions, so having to merge this linked commit made me realize $TERM is xterm-256color and $COLORTERM is undefined in Windows Terminal.

Until this issue changes (subscribe for issue updates) the update script will detect full color and choose the right palette after adding export COLORTERM=truecolor near the top of .zshrc

The new oh-my-zsh commit uses the XVilke gist that @heaths linked—although not the query method—so any other script using the variable check from this gist should also get support after defining COLORTERM. I imagine one could simply add this in .bashrc as well (or whichever dotfile is shell-relevant).

@PennRobotics commented on GitHub (Jan 11, 2022): [oh-my-zsh changed their update script to use truecolor if supported](https://github.com/ohmyzsh/ohmyzsh/commit/fbdc078fa60c2c34a7f5078846902538d162fbee#diff-4b98dbe69610bd8f3e7440e55255e2fd22da4659b509cefbe976c3e03d6458e0). I had replaced the omz ASCII art and color definitions, so having to merge this linked commit made me realize $TERM is xterm-256color and $COLORTERM is undefined in Windows Terminal. Until this issue changes (subscribe for issue updates) the update script will detect full color and choose the right palette after **adding `export COLORTERM=truecolor` near the top of .zshrc** The new oh-my-zsh commit uses the [XVilke gist](https://github.com/microsoft/terminal/issues/11057#issuecomment-908481176) that @heaths linked—although not the query method—so any other script using the variable check from this gist should also get support after defining COLORTERM. I imagine one could simply add this in .bashrc as well (or whichever dotfile is shell-relevant).

claunia commented

@j4james commented on GitHub (Jan 11, 2022):

Just FYI, that COLORTERM test in oh-my-zsh is essentially useless, because any terminal that doesn't support the RGB color sequences is also not likely to support the fallback 256-color sequences. They'll potentially just end up with a bunch of blinking text as a result of the 5 in the SGR. It's possible they just don't care about supporting older terminals, but then they might as well use the RGB colors for everyone and not bother with the COLORTERM test.

@j4james commented on GitHub (Jan 11, 2022): Just FYI, that `COLORTERM` test in oh-my-zsh is essentially useless, because any terminal that doesn't support the RGB color sequences is also not likely to support the fallback 256-color sequences. They'll potentially just end up with a bunch of blinking text as a result of the 5 in the SGR. It's possible they just don't care about supporting older terminals, but then they might as well use the RGB colors for everyone and not bother with the `COLORTERM` test.

claunia commented

@jredfox commented on GitHub (Jun 10, 2022):

ok after looking $COLORTERM is to be the only color. if it's the same name as $TERM then that's a bug on the terminal. tested on linux terminals some do contain the bug others do not but it wouldn't make sense why $COLORTERM would be equal to $TERM

@jredfox commented on GitHub (Jun 10, 2022): ok after looking `$COLORTERM` is to be the only color. if it's the same name as `$TERM` then that's a bug on the terminal. tested on linux terminals some do contain the bug others do not but it wouldn't make sense why `$COLORTERM` would be equal to `$TERM`

claunia commented

@Diablo-D3 commented on GitHub (Jun 10, 2022):

COLORTERM only has one meaningful value: truecolor. If a terminal isn't true color, the variable should remain unset.

@Diablo-D3 commented on GitHub (Jun 10, 2022): `COLORTERM` only has one meaningful value: `truecolor`. If a terminal isn't true color, the variable should remain unset.

claunia commented

@jredfox commented on GitHub (Jun 10, 2022):

No I seen lots of Linux terminals that return xterm-256 from that variable. If it’s unset that means it’s an older terminal then you should also look for $TERM but $TERM a lot of times gets set to an older color value such as xterm not 256 and xterm-256 even if it supports true color that value will remain non true color regardless.

Example easily produced. gnome-terminal latest linux mint distro. print $TERM and $COLORTERM it will give you xterm-256color or was it xterm-256, fallowed by truecolor

@jredfox commented on GitHub (Jun 10, 2022): No I seen lots of Linux terminals that return xterm-256 from that variable. If it’s unset that means it’s an older terminal then you should also look for $TERM but $TERM a lot of times gets set to an older color value such as xterm not 256 and xterm-256 even if it supports true color that value will remain non true color regardless. Example easily produced. `gnome-terminal` latest linux mint distro. print `$TERM` and `$COLORTERM` it will give you xterm-256color or was it xterm-256, fallowed by truecolor

claunia commented

@Diablo-D3 commented on GitHub (Jun 11, 2022):

TERM should return xterm-256color if it is a modern term that chooses to implement xterm as-is; gnome-terminal uses libvte, and libvte-based terminals, as far as I know, do not implement COLORTERM incorrectly. What you are describing sounds like a bug with gnome-terminal if you are accurately describing it.

Software out there that implements truecolor either check if COLORTERM contains truecolor and/or 24bit, or in some cases, is simply set at all. I have not seen one that checks for equals exactly 'truecolor', which allows what I think you described to work (COLORTERM=xterm-truecolor).

@Diablo-D3 commented on GitHub (Jun 11, 2022): `TERM` should return xterm-256color if it is a modern term that chooses to implement xterm as-is; `gnome-terminal` uses `libvte`, and `libvte`-based terminals, as far as I know, do not implement `COLORTERM` incorrectly. What you are describing sounds like a bug with `gnome-terminal` if you are accurately describing it. Software out there that implements truecolor either check if `COLORTERM` contains `truecolor` and/or `24bit`, or in some cases, is simply set at all. I have not seen one that checks for equals exactly 'truecolor', which allows what I think you described to work (`COLORTERM=xterm-truecolor`).

claunia commented

@eggbean commented on GitHub (Sep 19, 2022):

Is there a way to make Windows Terminal set $COLORTERM in the settings file? If not, how can I make a bash conditional statement to determine if the terminal is Windows Terminal so I can set it in ~/.bash_profile?

@eggbean commented on GitHub (Sep 19, 2022): Is there a way to make Windows Terminal set `$COLORTERM` in the settings file? If not, how can I make a bash conditional statement to determine if the terminal is Windows Terminal so I can set it in `~/.bash_profile`?

claunia commented

@heaths commented on GitHub (Sep 19, 2022):

Is there a way to make Windows Terminal set $COLORTERM in the settings file? If not, how can I make a bash conditional statement to determine if the terminal is Windows Terminal so I can set it in ~/.bash_profile?

@eggbean you can check for $WT_SESSION - if it's defined at all - and conditionally set $COLORTERM. But, yeah, I agree: it'd be nice if WT just did this automatically.

@heaths commented on GitHub (Sep 19, 2022): > Is there a way to make Windows Terminal set `$COLORTERM` in the settings file? If not, how can I make a bash conditional statement to determine if the terminal is Windows Terminal so I can set it in `~/.bash_profile`? @eggbean you can check for `$WT_SESSION` - if it's defined at all - and conditionally set `$COLORTERM`. But, yeah, I agree: it'd be nice if WT just did this automatically.

claunia commented

@eggbean commented on GitHub (Sep 19, 2022):

@heaths Thanks.

@eggbean commented on GitHub (Sep 19, 2022): @heaths Thanks.

claunia commented

@jredfox commented on GitHub (Oct 11, 2022):

Nah tested on 40 Linux terminals colorterm not being set doesn't mean it's going to be true color

@jredfox commented on GitHub (Oct 11, 2022): Nah tested on 40 Linux terminals colorterm not being set doesn't mean it's going to be true color

claunia commented

@mikehearn commented on GitHub (Apr 1, 2023):

Unfortunately $WT_SESSION turns out to not be reliable (sigh). Here's a funny trick:

Open Explorer
Right click on a folder whilst holding the shift key
Select "Show more options"
click "open powershell window here"
Observe that although what you get is Windows Terminal, WT_SESSION does not exist in the environment.

Why not? I have no idea and don't wish to spend time finding out.

Please please please just implement TERM_PROGRAM and other user agent strings. Yes, feature detection, I know. It's a lovely idea but it will never be enough by itself. In our case we're trying to detect WT specifically because there are bugs in the old legacy terminal, maybe in old versions of Windows I don't know, for example setting the console to UTF-8 will change the font in every single legacy console window. That annoys people who for whatever reason prefer to use that vs the new WT (they exist, I've worked with them) and so we just say oh whatever, if you use old stuff you get old stuff. That's why we want to detect WT, it's more like a negative detection and thus feature detection won't ever work because old conhost will gamely advertise that it has these features and then do the wrong thing.

Yep, it does create other problems. Non-WT terminals that use the same codepaths, for example. Fine, a problem for another day. They can advertise themselves as "Windows Terminal/5 (compatible; FooTerm)" and that's OK.

@mikehearn commented on GitHub (Apr 1, 2023): Unfortunately `$WT_SESSION` turns out to not be reliable (sigh). Here's a funny trick: * Open Explorer * Right click on a folder _whilst holding the shift key_ * Select "Show more options" * click "open powershell window here" * Observe that although what you get is Windows Terminal, `WT_SESSION` does not exist in the environment. Why not? I have no idea and don't wish to spend time finding out. Please please please just implement TERM_PROGRAM and other user agent strings. Yes, feature detection, I know. It's a lovely idea but it will never be enough by itself. In our case we're trying to detect WT specifically because there are bugs in the old legacy terminal, maybe in old versions of Windows I don't know, for example setting the console to UTF-8 will change the font in every single legacy console window. That annoys people who for whatever reason prefer to use that vs the new WT (they exist, I've worked with them) and so we just say oh whatever, if you use old stuff you get old stuff. That's why we want to detect WT, it's more like a negative detection and thus feature detection won't ever work because old conhost will gamely advertise that it has these features and then do the wrong thing. Yep, it does create other problems. Non-WT terminals that use the same codepaths, for example. Fine, a problem for another day. They can advertise themselves as "Windows Terminal/5 (compatible; FooTerm)" and that's OK.

claunia commented

@zadjii-msft commented on GitHub (Apr 3, 2023):

@mikehearn what you're seeing there is #13006 and is a Hard problem - in that scenario, powershell.exe was launched outside of the Terminal, then later attached to it. WT was not involved in launching it at all, so it had no opportunity to add any environment variables. Not even conhost would have a chance to say "I'm conhost, NOT Terminal" here!

@zadjii-msft commented on GitHub (Apr 3, 2023): @mikehearn what you're seeing there is #13006 and is a **H**ard problem - in that scenario, `powershell.exe` was launched outside of the Terminal, then later attached to it. WT was not involved in launching it _at all_, so it had no opportunity to add _any_ environment variables. Not even conhost would have a chance to say "I'm conhost, NOT Terminal" here!

claunia commented

@mikehearn commented on GitHub (Apr 3, 2023):

Huh, OK, that's an interesting problem indeed. I guess ANSI escapes to do feature detection and/or getting a user-agent equivalent would be the only way forward there.

@mikehearn commented on GitHub (Apr 3, 2023): Huh, OK, that's an interesting problem indeed. I guess ANSI escapes to do feature detection and/or getting a user-agent equivalent would be the only way forward there.

claunia commented

@heaths commented on GitHub (Apr 3, 2023):

Much of this issue has talked about corner cases where setting TERM=xterm-256 and COLORTERM=truecolor may not be 100% accurate, but as has come up many times, it seems no terminal is perfect. Yet, the computing world carries on. Terminal programs are being run in mind-boggling numbers every minute of every day, and the overall experience is still fine. Sometimes those programs will add workarounds themselves to odd but significant enough problems.

Is it really worth not setting the variables as describe above in spite of all the programs that would work just fine? Feature detection based on ANSI sequences is burdensome for every program to implement when a couple of env vars are much easier to check and correct in the vast majority of cases. And feature detection via ANSI escape sequences don't give you the full picture anyway. Just because it reports truecolor doesn't mean it supports hyperlinks. And it's been discussed how different terminals respond to : or ; separators while some support either. It's already a grab bag of different behaviors. Why make it harder?

@heaths commented on GitHub (Apr 3, 2023): Much of this issue has talked about corner cases where setting `TERM=xterm-256` and `COLORTERM=truecolor` may not be 100% accurate, but as has come up many times, it seems no terminal is perfect. Yet, the computing world carries on. Terminal programs are being run in mind-boggling numbers every minute of every day, and the overall experience is still fine. Sometimes those programs will add workarounds themselves to odd but significant enough problems. Is it really worth not setting the variables as describe above in spite of all the programs that would work just fine? Feature detection based on ANSI sequences is burdensome for *every* program to implement when a couple of env vars are much easier to check and correct in the vast majority of cases. And feature detection via ANSI escape sequences don't give you the full picture anyway. Just because it reports truecolor doesn't mean it supports hyperlinks. And it's been discussed how different terminals respond to `:` or `;` separators while some support either. It's already a grab bag of different behaviors. Why make it harder?

claunia commented

@CannibalVox commented on GitHub (Nov 16, 2024):

What is the actual status of this ticket? I see earlier in the ticket that there was some resistence to using $COLORTERM, but then broadly there seems to be support, even from maintainers, throughout the rest of the ticket. The ticket is tagged with "Help Wanted". Is this ticket really waiting for someone to come along and add a single environment variable in a PR?

@CannibalVox commented on GitHub (Nov 16, 2024): What is the actual status of this ticket? I see earlier in the ticket that there was some resistence to using $COLORTERM, but then broadly there seems to be support, even from maintainers, throughout the rest of the ticket. The ticket is tagged with "Help Wanted". Is this ticket really waiting for someone to come along and add a single environment variable in a PR?

claunia commented

@AnalogFeelings commented on GitHub (Dec 17, 2024):

Lack of COLORTERM makes onefetch fall back to 16 color mode, is this going to be fixed any time soon?

@AnalogFeelings commented on GitHub (Dec 17, 2024): Lack of `COLORTERM` makes [onefetch](https://github.com/o2sh/onefetch/tree/main) fall back to 16 color mode, is this going to be fixed any time soon?

claunia commented

@ldemailly commented on GitHub (Apr 26, 2025):

what is the mechanism to easily detect that windows terminal does support truecolor (it does) - ideally through env.
I'm not seeing anything in dir env: actually (on windows powershell before starting my program), TERM is there in bash though but set wrong (xterm-256) without COLORTERM

@ldemailly commented on GitHub (Apr 26, 2025): what is the mechanism to easily detect that windows terminal does support truecolor (it does) - ideally through env. I'm not seeing anything in `dir env:` actually (on windows powershell before starting my program), TERM is there in bash though but set wrong (xterm-256) without COLORTERM

claunia commented

@heaths commented on GitHub (Apr 28, 2025):

With environment variables there really isn't, hence the ask. You have to write code to either call Windows-specific APIs or to write a VT sequence to the terminal and check the response. Neither is ideal, hence this feature request.

@heaths commented on GitHub (Apr 28, 2025): With environment variables there really isn't, hence the ask. You have to write code to either [call Windows-specific APIs](https://docs.microsoft.com/windows/console/console-virtual-terminal-sequences) or to write a VT sequence to the terminal and check the response. Neither is ideal, hence this feature request.

claunia commented

@j4james commented on GitHub (Apr 28, 2025):

Well now that Windows Terminal supports the colon version of the ITU format, you can always just use that with a fallback to ANSI colors, e.g. something like this:

printf "\e[33;44m\e[38:2::255:187:114;48:2::65:114:226m TEST \e[m\n"

On the Window 10 console, and older versions of Windows Terminal, that'll give you the ANSI colors.

And on more recent versions of Windows Terminal you'll get the 24-bit colors.

There'll probably be terminals where that doesn't work correctly, so you might get no colors at all, or some form of messed up attributes, but that's their bug to fix.

@j4james commented on GitHub (Apr 28, 2025): Well now that Windows Terminal supports the colon version of the ITU format, you can always just use that with a fallback to ANSI colors, e.g. something like this: ```bash printf "\e[33;44m\e[38:2::255:187:114;48:2::65:114:226m TEST \e[m\n" ``` On the Window 10 console, and older versions of Windows Terminal, that'll give you the ANSI colors. ![Image](https://github.com/user-attachments/assets/2723b3e8-89a8-483a-8262-3889b08ac271) And on more recent versions of Windows Terminal you'll get the 24-bit colors. ![Image](https://github.com/user-attachments/assets/bcb70ade-cfe9-470b-a66a-1e0a7a3728ac) There'll probably be terminals where that doesn't work correctly, so you might get no colors at all, or some form of messed up attributes, but that's their bug to fix.

claunia commented

@heaths commented on GitHub (Apr 29, 2025):

@j4james while that is good news, it doesn't fix the hundreds or thousands of apps/scripts out there that rely on COLORTERM already. Expecting everyone to update to support Windows - when most of those were already born out of linux and/or macOS (NextOS) - doesn't seem as feasible as defining COLORTERM appropriately.

@heaths commented on GitHub (Apr 29, 2025): @j4james while that is good news, it doesn't fix the hundreds or thousands of apps/scripts out there that rely on `COLORTERM` already. Expecting everyone to update to support Windows - when most of those were already born out of linux and/or macOS (NextOS) - doesn't seem as feasible as defining `COLORTERM` appropriately.

claunia commented

@ldemailly commented on GitHub (Apr 29, 2025):

Also note that for performance critical TUIs (I know I know yet... that's what I do) sending both sets of color isn't really an option, that would bloat the data sent too much so I need to know if it's truecolor or not, I think I will do something ugly like if I am running on Windows, assume it's truecolor irrespective of TERM (I don't plan on supporting older non true color windows terminal, plus the end user could downgrade if needed, I'm just trying to have the default the most likely correct one)

@ldemailly commented on GitHub (Apr 29, 2025): Also note that for performance critical TUIs (I know I know yet... that's what I do) sending both sets of color isn't really an option, that would bloat the data sent too much so I need to know if it's truecolor or not, I think I will do something ugly like if I am running on Windows, assume it's truecolor irrespective of TERM (I don't plan on supporting older non true color windows terminal, plus the end user could downgrade if needed, I'm just trying to have the default the most likely correct one)

claunia commented

@heaths commented on GitHub (Apr 29, 2025):

I think I will do something ugly like if I am running on Windows, assume it's truecolor irrespective of TERM

Given the support matrix, this is probably safe these days - especially among the dev community; however, I just wanted to point out this feature was mainly about fixing not only ever future app that is cross-plat, but all those that already exist and check TERM and/or COLORTERM. I wouldn't expect all those to "fix" themselves just for Windows. It's already bad enough across numerous ecosystems that many maintainers even today have no idea Windows has - for a sufficiently long time now - supported VT sequences. So many comments in various code bases I see, like, "Windows doesn't support ANSI color / PTY, so do nothing here."

Let's meet developers where they already are as much as possible, IMO. Setting COLORTERM=truecolor seems like a fairly easy, innocuous win.

@heaths commented on GitHub (Apr 29, 2025): > I think I will do something ugly like if I am running on Windows, assume it's truecolor irrespective of TERM Given the support matrix, this is probably safe these days - especially among the dev community; however, I just wanted to point out this feature was mainly about fixing not only ever future app that is cross-plat, but all those that already exist and check `TERM` and/or `COLORTERM`. I wouldn't expect all those to "fix" themselves just for Windows. It's already bad enough across numerous ecosystems that many maintainers even today have no idea Windows has - for a sufficiently long time now - supported VT sequences. So many comments in various code bases I see, like, "Windows doesn't support ANSI color / PTY, so do nothing here." Let's meet developers where they already are as much as possible, IMO. Setting `COLORTERM=truecolor` seems like a fairly easy, innocuous win.

claunia commented

@ldemailly commented on GitHub (Apr 29, 2025):

Totally agree that would be best, I was just saying what I may personally do in the meanwhile. I also thought I understood that terminal doesn’t actually control the environment for say powershell which makes it not possible to just set COLORTERM (without some magic handshake?)

@ldemailly commented on GitHub (Apr 29, 2025): Totally agree that would be best, I was just saying what I may personally do in the meanwhile. I also thought I understood that terminal doesn’t actually control the environment for say powershell which makes it not possible to just set COLORTERM (without some magic handshake?)

claunia commented

@j4james commented on GitHub (Apr 29, 2025):

I also thought I understood that terminal doesn’t actually control the environment

Yeah, this was explained earlier in the thread. I was actually somewhat in favor of COLORTERM at one point, until I tried adding it to Windows Terminal and found it didn't actually work half the time. It would just be a never ending source of bug reports.

@j4james commented on GitHub (Apr 29, 2025): > I also thought I understood that terminal doesn’t actually control the environment Yeah, this was explained earlier in the thread. I was actually somewhat in favor of `COLORTERM` at one point, until I tried adding it to Windows Terminal and found it didn't actually work half the time. It would just be a never ending source of bug reports.

claunia commented

@Kazmirchuk commented on GitHub (Apr 29, 2025):

FWIW I've just added SetEnv COLORTERM=truecolor in my .ssh/config, I guess this is easy enough (+ACCEPT_ENV in sshd config on the server). However, many people might not even know about existence and meaning of $COLORTERM, so it would be nice to mention it in the official docs. Some chapter like "Tips to get the best out of your Windows Terminal experience"

@Kazmirchuk commented on GitHub (Apr 29, 2025): FWIW I've just added `SetEnv COLORTERM=truecolor` in my `.ssh/config`, I guess this is easy enough (+ACCEPT_ENV in sshd config on the server). However, many people might not even know about existence and meaning of $COLORTERM, so it would be nice to mention it in the official docs. Some chapter like "Tips to get the best out of your Windows Terminal experience"

claunia commented