The issue clearly identifies a logic ordering problem in color depth detection when running under tmux.
The issue reports that `getColorDepth()` incorrectly returns 8-bit color depth when running under tmux with truecolor support due to checking `TMUX` before `COLORTERM`. The fix requires reordering these checks while maintaining backward compatibility for tmux sessions without truecolor support.
In lib/internal/tty.js, getColorDepth() checks env.TMUX (line 174) before env.COLORTERM (line 215). When TMUX is set, it returns COLORS_256 (8) immediately, never reaching the COLORTERM === 'truecolor' check that would return COLORS_16m (24).
tmux has supported true color since v2.2 (2016). Modern tmux sets COLORTERM=truecolor when the outer terminal supports RGB via terminal-features or terminal-overrides. The current ordering ignores this.
Note: PR #30474 previously reordered COLORTERM before the TERM check but did not address the TMUX check ordering.
const tty = require('tty');
console.log('TMUX:', process.env.TMUX || '(unset)');
console.log('COLORTERM:', process.env.COLORTERM || '(unset)');
console.log('getColorDepth():', process.stdout.getColorDepth());
Inside tmux (with COLORTERM=truecolor):
TMUX: /private/tmp/tmux-501/default,9842,1
COLORTERM: truecolor
getColorDepth(): 8 # ← wrong, should be 24
With TMUX= unset:
TMUX: (unset)
COLORTERM: truecolor
getColorDepth(): 24 # ← correct
Move the COLORTERM truecolor/24bit check (line 215) before the TMUX check (line 174):
// Check COLORTERM first — tmux sets this when RGB is supported
if (env.COLORTERM === 'truecolor' || env.COLORTERM === '24bit') {
return COLORS_16m;
}
if (env.TMUX) {
return COLORS_256;
}
This preserves the TMUX → 256 fallback for tmux sessions that don't have truecolor configured, while correctly returning 16m for those that do.
TERM 256 check (but not before TMUX)Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!