Or is there some voodoo by which the ANSI sequences get stripped from the output when redirected to a file?
Or is there some voodoo by which the ANSI sequences get stripped from the output when redirected to a file?
Not quite, but programs in general use some voodoo to detect when they are being redirected and won't output ANSI codes when they detect that.
Often there will be a flag to enable/disable color, or let it detect when color is desired. On Linux ls accepts the --color=WHEN parameter, where WHEN can be always (`ls --color=always > ls-with-ansi-codes.txt` will output color codes), it can be never (just don't output ANSI codes, no matter whether you detect output redirection) or it can be auto (will show colors when you execute `ls --color=auto` but not when you do `ls --color=auto > ls-without-ansi-codes.txt`).
On posix platforms, there's an API to check if a given file handle is a tty or not. https://github.com/corasaurus-hex/isatty/blob/main/isatty.c is an example of using the API, in a Janet context.
I assume that .NET's support for Linux/macOS is using that API decide if it should strip color codes or not.
Have you double checked with s hex editor what is in the txt file? Suppose it could also be your text editor that doesn't want to render those codes.
Often times libraries that let you specify output color will helpfully query the capabilities of the output device, and avoid writing the control codes if it’s (for example) a plain text file.