Skip to content

Colour

A tool decides whether to colour its output by asking whether it is talking to a terminal. Nothing that captures output is one — footman spawns over pipes, CI spawns over pipes — so tools go monochrome exactly when a build log would most benefit from the colour. toolroom forces the question instead of leaving it to the pipe.

Most tools take the answer from the environment (FORCE_COLOR, NO_COLOR). A few ignore it and need their own switch, which is why this table exists: each direction is probed, never assumed. Every tool below was run with colour forced both ways and the bytes read, so a cell says what that tool actually did.

Read it as: environment — the variables are enough; a switch — that flag is passed for you; no colour over a pipe — the tool has no way to be talked into it; can't silence — it colours regardless, an honest limitation rather than a silent strip (toolroom never rewrites a tool's bytes, because it cannot tell a stray escape from a deliberate one).

Tool Colour on Colour off
basedpyright environment environment
build environment environment
bun environment environment
claude — (no colour over a pipe) —
cmake environment environment
coverage — (no colour over a pipe) —
cspell --color environment
djlint — (no colour over a pipe) —
docker (pass-through wrapper)
eclint — (no colour over a pipe) —
gh environment environment
git -c color.ui=always environment
git_changelog environment environment
git_cliff environment can't silence
markdownlint — (no colour over a pipe) —
mkdocs — (no colour over a pipe) —
mypy environment environment
ninja environment environment
prek environment environment
pytest environment environment
python — (no colour over a pipe) —
ruff environment environment
ruff_format environment environment
tea environment can't silence
twine environment can't silence
ty environment environment
uv environment environment
zensical — (no colour over a pipe) —