This is expected behavior (similar to many other CLI tools btw). By default --color-output mode is auto, i.e. it will use color if isatty() returns True, which is never the case for pipes.

@ilevkivskyi To me the docstring was suggestion something else, but yes it is not very clear:

  --no-color-output         Do not colorize error messages (inverse: --color-
                            output)

To me the inverse of forcing color off would be forcing color on. Also just, the imperative wording "color output" very much sounds like "force" to me. I'm literally telling mypy to color the output, not --color-output-if-possible.

This raises the question what effect --color-output actually has, because without specifying anything, the logic uses auto-detection anyway, right? So doesn't that mean that --color-output is a command line argument that does nothing?

My expectation was that --color-output is more like the common --color=yes or --color=always, which add meaningful functionality, because they allow turning off the auto-detection, and enforcing colors. This is basically something most other tools offer in one way or another. Here for instance in the example of pytest:

Should I instead open a feature request for that?

I agree. Supplying --color-output should mean: I don't care whether I'm in a tty or not: output in color. --no-color-output should mean: I don't care whether I'm in a tty or not: do not output in color. Not supplying either should mean: output in color if this is a tty, otherwise don't output in color. Otherwise supplying --color-output is no different from not supplying either argument.