--no-color sets process.env.NO_COLOR globally and likely does not disable colour

[royalpinto007]

Desired outcome

--no-color actually strips colour, and rendering a report does not mutate the process environment.

Why it matters

src/reporters/terminal.ts:

const useColor = options.color ?? true;
if (!useColor) {
  // picocolors respects NO_COLOR, but honor an explicit override too.
  process.env.NO_COLOR = "1";
}

Two problems.

1. It probably does not work. picocolors decides whether colour is supported once, when the module is first imported, and exposes the result as isColorSupported. By the time renderTerminal runs, pc.red and friends are already bound to either the colouring or the pass-through implementations. Setting process.env.NO_COLOR after import does not retroactively change that, so mcp-audit --no-color (src/cli.ts line 189, documented at line 65) can still emit ANSI escapes into a redirected file or a CI log.

2. It is a global side effect from a pure-looking render function. renderTerminal is exported from the package (src/index.ts), so a library consumer who renders one report with color: false has NO_COLOR=1 set for the rest of their process, silently changing the behaviour of every other library they use. It is never restored.

Steps

1. Use picocolors' explicit constructor instead of the environment: import { createColors } from "picocolors" and build a colour object with createColors(useColor), then use that instead of the default pc import inside renderTerminal and renderSummary.
2. Delete the process.env.NO_COLOR assignment.
3. renderSummary is exported separately and also uses the module-level pc, so it needs the colour object passed in or a parameter of its own.
4. Add a test in test/reporters.test.ts asserting the output of renderTerminal(result, { color: false }) contains no ANSI escape sequences, and that process.env.NO_COLOR is unchanged afterwards.

Claiming this

Comment below to claim it. A reply usually comes within a day.