The 'gray' color name resolves to nothing, including on the default separators

Author: zachthedevCreated Aug 6, 2026Updated Aug 6, 2026

Problem

gray is not a name in COLOR_MAP. The neutral entry is brightBlack (src/utils/colors.ts:29), and getColorAnsiCode returns '' on a lookup miss with no fallback (colors.ts:249-250). Every site naming gray renders with no color rather than the gray it asks for.

Four sites, all outside the TUI:

  • src/utils/renderer.ts:1051, let separatorColor = widget.color ?? 'gray';
  • src/widgets/Version.ts:10, getDefaultColor()
  • src/widgets/TerminalWidth.ts:11, getDefaultColor()
  • src/widgets/GitSha.ts:22, getDefaultColor()

The renderer one is the default path rather than an edge case. inheritSeparatorColors defaults to false (src/types/Settings.ts:72) and the shipped default line carries three separators with no color set (Settings.ts:56, :58, :60), so a fresh install takes ?? 'gray' on every separator and gets nothing back.

This one is old, from 365b640, so it is not a regression.

Two ways to go

Deleting the fallback preserves behavior exactly and stops a dead name implying a color that never applied. Aliasing gray to brightBlack is what the code reads as intending, but it newly colorizes the separators of everyone who never set a separator color, plus the three widgets above.

I lean toward deleting, on the grounds that a silent visual change on upgrade is worse than a name that was never doing anything. Either is a small PR and I am happy to send whichever you prefer.

Worth noting #468 edits the getDefaultColor() resolution these three widgets go through, so if you want the alias it is cheapest to settle before that lands.

Not in scope either way: the color='gray' props in the Ink components. Those are chalk names, they resolve fine, and they have nothing to do with COLOR_MAP.