Fixing Wrong or Missing Colors in Windows Terminal When Using WSL

Wrong colors, missing colors entirely, or garbled special characters specifically inside Windows Terminal running a WSL distro — while the same shell configuration renders correctly elsewhere — usually comes down to one of a few specific, checkable settings.

Step 1: confirm the $TERM value WSL is actually using

echo $TERM

A value like xterm-256color supports full 256-color output; an unexpected or overly minimal $TERM value (or one not matching what your terminfo database actually has an entry for) can cause a shell or TUI application to fall back to a reduced color palette or garbled formatting.

Step 2: set TERM explicitly if it’s wrong or missing

export TERM=xterm-256color

Adding this to your WSL distro’s shell startup file (.bashrc or .zshrc) ensures a consistent, correctly-capable $TERM value regardless of what Windows Terminal happens to pass through by default in a given configuration.

Step 3: confirm Windows Terminal’s own color scheme and profile settings

Windows Terminal → Settings → your WSL profile →
  confirm "Color scheme" is set as expected, and that
  no custom scheme is unintentionally overriding it

Windows Terminal applies color scheme settings per-profile — confirm the specific profile connected to your WSL distro has the color scheme you actually intend, since a different, unrelated profile’s settings won’t apply here.

Step 4: check for a font missing required glyphs

Windows Terminal → Settings → your WSL profile →
  Appearance → Font face → confirm a Nerd Font variant
  if your prompt or TUI apps use icon glyphs

As with prompt theme issues generally, missing icon glyphs specifically (rather than wrong colors generally) usually trace back to the configured font lacking the specific glyph set a theme or tool expects, not a WSL-specific problem at all.

Step 5: check whether the issue is specific to WSLg GUI applications rather than the terminal itself

If the color issue is specifically inside a Linux GUI application running via WSLg (not the terminal/shell itself), that’s a separate rendering path entirely — WSLg’s own graphics stack is distinct from Windows Terminal’s text rendering, and troubleshooting steps for one don’t necessarily apply to the other.

Step 6: test the same shell config over a different connection method

# compare colors/rendering between:
# - Windows Terminal connected directly to the WSL distro
# - the same distro accessed via a plain SSH connection
#   from a different terminal emulator

If colors render correctly over SSH from a different terminal but incorrectly specifically in Windows Terminal, the problem is isolated to Windows Terminal’s specific configuration rather than anything in the shell or WSL distro’s own configuration.

Step 7: check for a stale Windows Terminal version

Microsoft Store → Windows Terminal → check for updates

Since Windows Terminal is actively, independently developed, a specific rendering bug affecting color or glyph handling may already be fixed in a newer release than the one currently installed.

Step 8: reset the specific WSL profile to Windows Terminal’s defaults as a last resort

Windows Terminal → Settings → your WSL profile →
  remove custom overrides, or delete and let Windows
  Terminal regenerate the profile automatically

If a specific profile’s configuration has accumulated conflicting or unclear customizations over time, resetting it and reapplying only the settings you actually need can resolve an otherwise hard-to-isolate combination of issues.

Why this specific combination — WSL, Windows Terminal, and the shell — has more moving parts than a native Linux terminal setup

A native Linux desktop’s terminal, shell, and font configuration are usually all managed within one coherent environment — the WSL-plus-Windows-Terminal setup spans a Windows-side terminal application, a Linux-side shell and $TERM configuration, and (for GUI apps) a separate WSLg rendering path, meaning a color or rendering issue can originate at any of several genuinely distinct layers, worth checking systematically rather than assuming the fix lives in whichever layer seems most obviously related.