There is no ANSI directive in the [TakeCommand] section.
There is an ANSI directive in the [4NT] section, which only determines whether to toggle the ANSI bit (with SetConsoleMode) in the console. All ANSI interpretation & display is done by Windows, not by TCC.
Something in your system (not TCC) is either not setting the ANSI directive, or turning it off in the console. (Do an "echo %_ansi" in the misbehaving console.)
I dunno. Here's TCMD and the console after being detached.
With that prompt, I never see a green prompt in TCMD. I had done some testing and found that ^e[32;1m, ^e[92m, and ^e[38;2;0;255;0m all put that attribute 0x000A in the console screen buffer, read with either ReadConsoleOutput or ReadConsoleOutputAttribute (does TCMD use one of those?). I'll do those tests again.
Have you (or anyone else) tried ^e[38;2;0;255;0m?
As you might have guessed, it's not only the prompt. Whenever I use ^e[38;2;0;255;0m in TCMD I get the default foreground color.
Using ReadConsoleOutput in a plugin I see (note: 0041 = 'A', 000A = BRI GRE).
With ReadConsoleOutputAttribute I see
My previous tests must have been flawed. I see that TCMD is OK. Changes in OpenConsole.exe (WindowsTerminal project) leak into CONHOST.EXE. I could ask about this in the WindowsConsole GitHub forum but I imagine it's impossible to turn a specification like ^e[38;2;R;G;Bm (24-bit color) into a 16-bit attribute in a reasonable way. There's still the question of why the two ways of getting the attrinute differ but that's of no concern here.